今日已更新 240 条资讯 | 累计 23823 条内容
关于我们

标签:#ai

找到 4245 篇相关文章

AI 资讯

Midjourney bought the astrology app Co-Star

Midjourney, which has gone from generating AI cat images to full-body ultrasound scans, is getting into a new field: astrology. The AI startup announced on Thursday that it has acquired the personalized astrology app Co-Star, as reported earlier by Bloomberg. Co-Star is a free app that offers daily horoscopes and allows you to check your […]

2026-07-25 原文 →
AI 资讯

Why Sick Patients Hate Your Cheerful Conversational Voice AI

Why Sick Patients Hate Your Cheerful Conversational Voice AI Picture an oncology patient sitting in the dark at three in the morning, nursing a severe bout of breakthrough pain. Desperate for assistance, she calls her clinic's scheduling and triage line. Instead of a calm, grounded response, she is greeted by an artificially bright synthetic voice: "Hi there! What a bright day to take care of your health!" The patient hangs up immediately. This reaction is far from an isolated incident. When individuals reach out to a medical office, they are rarely seeking entertainment or cheerful banter. They are frequently managing acute pain, administrative frustration, or intense health anxiety. When a high-stress emotional state collides with a forced, chipper baseline tone, the resulting healthcare voice AI tone mismatch creates severe cognitive friction. Patients perceive forced cheerfulness as cold apathy disguised as friendliness. In clinical communications, this phenomenon manifests as conversational AI toxic positivity. An upbeat virtual receptionist telling a patient with severe chest tightness that it would be "happy to help you today" projects a disturbing lack of situational awareness. Instead of humanizing the interaction, artificial warmth highlights the machine's non-human nature. It pushes the caller deep into the uncanny valley of simulated care, leaving patients feeling managed by a cost-cutting algorithm rather than supported by a dedicated care team. The Data Behind Patient Frustration Industry benchmarks reveal a profound disconnect between healthcare automation strategies and patient expectations. While health systems rapidly deploy patient experience virtual assistant models to offload administrative burden from front-desk staff, few organizations audit the emotional resonance of their automated telephony systems. Metric Patient / Consumer Reaction Source 68% Report heightened frustration when automated healthcare voice systems use overly enthusiastic or

2026-07-25 原文 →
AI 资讯

llms.txt: What It Actually Does, and Why It Rots

When ChatGPT, Claude or Perplexity answers a question about your product, it is not consulting a decade of PageRank. It fetches a handful of pages and tries to work out what your site is. That is a very different retrieval problem from classic search, and most sites are accidentally hostile to it. Why sitemaps are the wrong mental model A sitemap optimises for coverage — every URL, every paginated archive, every tag page. That is correct for a crawler with a huge budget and a ranking model to sort the noise afterwards. An LLM landing on your site has neither. It has a limited context window and one shot. If the first thing it ingests is 400 URLs of ?page=17 and /tag/misc , your three genuinely useful guides are buried. llms.txt inverts this. It is a small markdown file at your root that optimises for priority : # Your Product > One-line description of what this actually does. ## Docs - [ Quickstart ]( https://example.com/docs/quickstart ) : Install and first request in 5 minutes - [ API Reference ]( https://example.com/docs/api ) : Every endpoint with request/response examples Two rules make or break it: Every link carries a description. The colon-suffix annotation is what lets a model decide whether to fetch a page. A bare link list is barely better than a sitemap. Omit aggressively. If a page does not answer a question someone would ask, it does not belong. llms-full.txt and the context tradeoff llms-full.txt inlines expanded content rather than linking out, so a model can ingest everything in one request. This is genuinely useful for compact docs — and actively harmful for large sites, where you will blow the context window and get truncated mid-document. Rough heuristic: if your docs exceed roughly 50k tokens, ship llms.txt alone and let models fetch selectively. The part nobody mentions: it rots This is where most implementations quietly fail. You write the file, ship it, and three months later half the descriptions describe features you renamed and two links 4

2026-07-25 原文 →
AI 资讯

Roku raises streaming hardware prices by up to $50

Roku has increased prices across its streaming hardware, with the cheapest HD Streaming Stick now priced at $39.99 instead of $29.99, as first reported by The Desk. The price hike affects all of Roku's other devices as well, with some increasing by as much as $50. Here's a rundown of the changes: Roku is currently […]

2026-07-25 原文 →
AI 资讯

Blade Runner 2099’s moody dystopia streams on Amazon in November

After teasing the series with some first-look images yesterday, Amazon is finally properly unveiling its Blade Runner streaming series. Called Blade Runner 2099, the show hits Prime Video on November 25th with all eight episodes dropping at once. We also got the first trailer for the series, which is full of Blade Runner staples: a […]

2026-07-25 原文 →
AI 资讯

You can’t ignore Google Zero anymore

The web and Google once had a deal: Google collects data and indexes webpages and in exchange sends oceans of traffic to websites. The deal wasn't perfect and certainly made Google more money than it made the websites, but it worked for a long time. Now, however, the deal seems to be dead. And the […]

2026-07-25 原文 →
AI 资讯

Meta is making its AI chatbot more like an assistant

Meta is upgrading its AI chatbot with new productivity features in a bid to compete with rivals like Gemini, ChatGPT, and Claude. The update will allow Meta AI to tap into your calendar to help you plan events and generate daily briefings, as well as perform in-depth research that you can steer as it progresses. […]

2026-07-25 原文 →
AI 资讯

How to Evaluate MCP Servers Before Installing Them (A Practical Checklist)

The MCP (Model Context Protocol) ecosystem is growing fast. There are now hundreds of MCP servers available — but how do you know which ones are worth installing? After building and evaluating 60+ MCP servers ourselves, we developed a practical checklist that saved us from shipping broken tools. Here's the framework we use. The Problem Most MCP server listings tell you what the server does. Very few tell you how well it does it. You install something that sounds perfect, then discover: It activates on the wrong prompts (false positives) It pulls irrelevant context (retrieval drift) It sounds confident but gives wrong answers (ungrounded reasoning) It never improves from feedback Sound familiar? The 5-Dimension Evaluation Checklist Before installing any MCP server, ask these questions: 1. Trigger Precision Question: Does this server activate when (and only when) it should? Red flags: Overly broad trigger descriptions ("use for anything related to X") No documented activation conditions Activates on common words that appear in unrelated contexts Green flags: Specific, documented trigger scenarios Clear non-activation cases listed Tested against diverse prompts 2. Retrieval Quality Question: Does it pull the right context for the task? Red flags: Returns large chunks without filtering No citation or source tracking Retrieves plausible but outdated information Green flags: Targeted, minimal context retrieval Source attribution for every piece of context Version-aware (knows when data might be stale) 3. Reasoning Grounding Question: Are its conclusions tied to actual data? Red flags: Generates advice without referencing specific inputs Can't explain its reasoning chain Confident answers that contradict its own retrieved context Green flags: Every conclusion references specific evidence Explicitly flags uncertainty Gracefully handles missing information 4. Output Usefulness Question: Does the output actually solve your problem? Red flags: Generic responses that could appl

2026-07-24 原文 →
AI 资讯

OpenAI vs Anthropic API for Production SaaS Features: A Technical Comparison

Every engineering team that ships an AI feature eventually has the same meeting: someone pulls up a pricing page, someone else pastes a benchmark screenshot from a forum post, and the decision gets made on vibes. That's a bad way to pick the model provider your product will depend on for the next two years. The OpenAI vs Anthropic API decision isn't really about which model is "smarter" this quarter — model quality leapfrogs every few months, and today's edge is gone by the next release cycle. What actually determines whether your AI feature is pleasant to build, cheap to run, and easy to maintain is the shape of the API underneath it: how it handles conversation state, how reliably it calls tools, how it prices repeated context, and how much application logic ends up welded to one vendor's conventions. This post is a practical, engineering-first look at those structural differences, written for teams past the demo stage trying to ship something that works in production, at scale, for paying customers. Why the OpenAI vs Anthropic API Comparison Matters More Than Model Quality It's tempting to treat this as a leaderboard question — whichever model scores higher on the latest benchmark wins. That's the wrong axis to optimize for a production SaaS feature. Benchmarks measure narrow tasks under ideal conditions; your feature has to survive malformed input, network failures, cost constraints, and the reality that whatever model you pick today will be superseded within months. What doesn't change as quickly is the API contract: request and response schema, conventions for multi-turn state, the tool-calling protocol, and the caching and rate-limiting behavior your infrastructure has to accommodate. Get those decisions right and swapping model versions later is a config change. Get them wrong and you're rewriting your orchestration layer every time a new model ships. That's why an OpenAI vs Anthropic API comparison for a production team should spend more time on API design

2026-07-24 原文 →
AI 资讯

JSON Schema Doesn't Prevent AI Hallucinations (And That's Okay)

A few months ago, if you had asked me whether Structured Outputs solved hallucinations, I probably would have said yes. Today, I wouldn't. Not because Structured Outputs don't work-they absolutely do. But because they solve a different problem . After building ShapeCraft, an open-source structured output library supporting OpenAI, Groq, Ollama (GBNF), and Anthropic, I realized something that fundamentally changed how I think about production AI. Structure and correctness are two completely different guarantees. The misconception Let's say you're extracting data from an invoice. The invoice says: Invoice Total: $900 Your model returns: { "invoiceTotal" : 1200 } Let's validate it. Validation Result Valid JSON ✅ Matches JSON Schema ✅ Required field present ✅ Correct data type ✅ Correct answer ❌ The response is structurally perfect. The extracted value is still wrong. JSON Schema didn't fail. It did exactly what it was designed to do. What JSON Schema actually guarantees JSON Schema is responsible for ensuring your application receives data in a predictable format. It guarantees things like: Valid JSON Required fields Correct data types Nested object structure Array validation Enum validation That makes applications dramatically easier to build. But it does not guarantee: The extracted value is correct The answer exists in the source document The model didn't hallucinate Business rules were followed Those are different problems. Structure ≠ Truth I've started thinking about AI validation as two independent layers. Layer 1 - Structural Validation Can my application safely consume this response? Examples: Is it valid JSON? Does it match my schema? Are required fields present? JSON Schema solves this extremely well. Layer 2 - Semantic Validation Can I trust the information? Questions become: Did the model extract the correct value? Can I trace it back to the source? Is there supporting evidence? Would I make a business decision based on this response? This layer is much ha

2026-07-24 原文 →
AI 资讯

Testing Microsoft Agent Framework Applications

This is Part 18 of my series on the Microsoft Agent Framework. You can read the original post over on lukaswalter.dev . In the previous article , we looked at observability for agents. The main idea was to make a run visible as a chain of model calls, tool calls, approvals, and workflow events. Testing starts from the same idea. An agent run is not one answer string. It is a small application flow with several boundaries: user input -> prompt and context -> model request -> model response -> tool selection -> tool arguments -> tool execution -> structured result or final answer -> routing or workflow state If the only test is an end-to-end prompt against a live model, all of those boundaries are mixed together. When the test fails, you do not know whether the problem is the prompt, the model, the tool schema, the router, the workflow, or the real dependency behind the tool. The solution is not to pretend that an LLM is deterministic. The solution is to test each boundary at the level where it is deterministic, then add a smaller number of evaluation-style tests for behavior that genuinely depends on the model. This post covers: fake model clients tool contract tests structured output tests routing tests workflow tests eval-style regression checks The examples use xUnit-style assertions, but the testing approach does not depend on xUnit. The snippets focus on the relevant testing boundary and omit some application-specific factory and workflow setup. Do not start with the live model A live model test is useful. It is also expensive, slow, sometimes flaky, and difficult to diagnose. That makes it a poor replacement for normal unit and integration tests. I use a testing pyramid for agent applications: evals realistic model and user examples application integration tests agent + tools + storage + workflow boundaries deterministic component tests fake model client, tools, schemas, routing The bottom layer should be the largest. It should catch ordinary programming mistak

2026-07-24 原文 →