AI 服务暂时不可用，以下为来源正文，待恢复后补全翻译。
Today, we're announcing a preview of a new class of System One-style models: extraction models. Our first one, Clairic, is available hosted on Workers AI as @cf/cloudflare/clairic.We intend to release the model open-weights soon. Clairic is an extraction model that is able to extract, compute, estimate, and forecast values from unstructured inputs — all at a significantly higher accuracy, faster latency, and cheaper cost than traditional LLMs. Context When System One models were announced by TypeSafe a month ago, it took the industry by storm. As referenced by TypeSafe in their blog and defined by Daniel Kahneman’s book Thinking, Fast and Slow, a System One model should be fast and precise, which contrasts a System Two model that is capable of deliberate reasoning (like LLMs). With this, TypeSafe introduced Jev — a model that is purpose-fit for a specific use case, and priced accessibly given its niche domain. It excelled where LLMs failed, helping users make decisions based on probabilities and well-typed outputs. The introduction of Jev prompted people to start thinking about a new class of models that were not LLMs and how to integrate them into their workflows. We were inspired by the concept of System One models and started thinking about other tasks where LLMs are inefficient. There are many structured-output calls going to frontier LLMs today with the same shapes again and again: What's the invoice total? When was this delivered? How many days late is it? What will this repair cost? What will traffic look like over the next 24 hours? None of these have answers you can list out in advance, which is needed for a decision model to give probabilities against. That led us to the class of models we're introducing today: System One extraction models. Introducing System One extraction models Until now, every System One model has been a decision model: Jev and Clef take an input state and a list of questions and give probabilities against the inputs and your listed questions. Clairic is the first model in a new class: System One extraction models. It is still fast, typed, and cheap, but it answers with values directly extracted from the input, computed from it, or predicted beyond it. Most model tasks ask for one of three kinds of output: a number, a choice from a fixed set, or open-ended text. Clairic handles the first, returning numbers with an 80% range, and also pulls typed values like names, dates and lists out of the input. Clef handles the second: it picks among options and returns a probability for each. LLMs handle the third. We call Clairic and Clef System One models because they answer in a single pass, without reasoning or generating tokens. They charge only for input and typically respond in under a second, while an LLM that reasons through the same step takes several seconds. An extraction model can return: Extracted values: Text copied from the input, such as a name, an order ID or a description. Each one comes back as a span with its character offsets and a confidence score. Including, computed values: Numbers, dates, times, datetimes, durations and lists, read from the input or worked out from it. They follow the rules of their type (for example, two decimals for cents) and come with a confidence score. Estimated values: Values the input doesn't state but gives evidence for. Each one comes back as a distribution inside the bounds you declare, on the grid you specify, with a median and an 80% interval. Forecasted values: Future values of a series, one estimate per step ahead, each with its own 80% interval. And because it generates no tokens, it can't produce a mistyped answer or “hallucinate” in the same way as an LLM (though it can, of course, make mistakes). Outputs are a value of the type you asked for, or null when the model fails to find an answer in the input. It also comes with confidence scores against the outputs to help you evaluate if it is appropriate to trust the model or to take a second look. Here’s how extraction models fit into the landscape of System One and System Two models: System One: Extract System One: Decide System Two Example models Clairic Jev, Clef GPT, Claude, Gemini, DeepSeek Sampling One parallel pass One parallel pass One token at a time Purpose Predict values Make decisions Write and reason ML framing Regression and extraction Classification Generation Thinking mode System 1: fast, one pass System 1: fast, one pass System 2: slow, deliberate Output Typed values: spans, numbers, dates, times, lists, distributions, with calibrated probabilities Typed decisions: options with calibrated probabilities Free-form strings Output space Continuous, but typed and bounded by your schema A finite set of options you list Anything What it answers What's the amount? When does it happen? How much will it be? Which category is it? Is it legitimate? Which action should we take? Why did it happen? How should we approach it? Can you fix it? Output always a valid response? Yes: every answer is a value of its declared type (or null), inside your bounds Yes: answers are always one of your options No: strings must be parsed and checked Together, these models can work together in unison to help you get closer to parsing through real-world data, making decisions on inputs, and then taking actions. Extraction models turn raw input into typed values, decision models turn values into decisions, and LLMs turn decisions into words. How a request works Clairic is designed differently than an LLM. Similar to a decision model, it only processes input tokens with a single forward pass, and thus has no charge for output tokens. It is much faster, cheaper, and more accurate than an LLM for certain use cases. A request is a state (the text to read, plus up to four optional images) and a map of typed fields. You name each field, give it a type and optional plain-language instructions, and get back one typed answer per field, all from one parallel pass. There is no reasoning and no output tokens – everything computes in a single forward pass, which means it is both fast and cheap. Type Returns text A specific span of the input, with its offsets number A number read or computed, honoring integer and decimals date, time, datetime Calendar dates and valid times, in ISO form duration A length of time in the unit you choose list Matching text, number or date, in input order estimate A distribution inside your [min, max], on your step grid, linear or log scale. forecast One estimate per future step of a series Every scalar answer comes with p_null (the probability that the value isn’t in the inputs) and confidence. Every estimate answer comes with a median and an 80% interval (p10 to p90), plus all 99 percentiles on request. There's no limit on the number of fields: if they don't fit beside the input in one pass, the server splits them into parallel passes that each see the whole input, then merges the answers. Here are some examples to illustrate the model’s features. Of course, using these features in a workflow would require appropriate inputs. An example: Extracting values Extraction is probably the most common job handed to LLMs today: "return the invoice number, vendor and due date as JSON." It works most of the time, but the failure modes are hard to catch. The output may not be valid JSON, a digit can be misread as it's generated, and once a text excerpt comes back, there's no way to trace it to where it appeared in the source. Most people build extraction pipelines to combat this, with multiple layers of parsing, schema validation, retries and spot checks. On top of that, you pay for reasoning and output tokens on every field of every document. Clairic operates differently; it doesn’t generate text answers. Instead, you get: Values extracted from your input, so an answer is grounded. Computed values, so it can parse through unstructured data without pre-sanitizing it. Character offset spans, so you can reference where in the input the data was. Confidence labels, so you can determine which values need a second look. A strongly typed output, so numbers and dates are formed under the rules of their type (e.g., a cents field has two decimals). Handling for null values, where a missing field returns with null as an answer (along with an estimated probability of null and a guess). Cheaper and faster answers, because every field is answered in the same parallel pass. So asking for thirty fields costs about the same as asking for three. Let’s walk through an example to illustrate the ways Clairic can extract values from unstructured data and make estimates. Take a customer support email: Hi, order A-88412 arrived on Sept 28, 2026 with a cracked screen and a dented corner. I paid $649.00 plus $52.10 tax. It's now Oct 9, 2026 and I'd like this fixed or refunded. Thanks, Dana From a Worker, you would make a request to Clairic to process this data: const { answers } = await env.AI.run("@cf/cloudflare/clairic", { state: email, fields: { order_id: { type: "text", instructions: "Order number" }, delivered_on: { type: "date", instructions: "Delivery date" }, amount_paid: { type: "number", decimals: 2, unit: "USD", instructions: "Total paid including tax" }, days_since_delivery: { type: "duration", unit: "days", integer: true, instructions: "Days from delivery to the date the customer wrote" }, damage: { type: "list", items: "text", instructions: "Each kind of damage described" }, tracking_number: { type: "text" }, }, }); Clairic returns the extracted values, spans in the input, probability that it is null (p_null) and confidence score: { "order_id": { "type": "text", "p_null": 3.4e-6, "span": [10, 17], "guess": "A-88412", "confidence": 0.999957, "value": "A-88412" }, "delivered_on": { "type": "date", "p_null": 6.5e-8, "guess": "2026-09-28", "confidence": 0.999999, "value": "2026-09-28" }, "amount_paid": { "type": "number", "p_null": 1.6e-5, "guess": 701.1, "confidence": 0.999944, "value": 701.1 }, "days_since_delivery": { "type": "duration", "p_null": 6.1e-9, "unit": "days", "guess": 11, "confidence": 0.999999, "value": 11 }, "damage": { "type": "list", "value": ["cracked screen", "dented corner"], "spans": [[50, 64], [71, 84]] }, "tracking_number": { "type": "text", "p_null": 1, "span": [106, 112], "guess": "$52.10", "confidence": 0.416016, "value": null } } A few things to notice: amount_paid isn't written anywhere in the email. In this example, Clairic added the price and the tax in the same pass and returns the sum. days_since_delivery is also worked out from two dates in the text, not directly in the input. damage lists both kinds of damage as exact spans, so you can highlight them in the source. tracking_number isn't in the email, so it comes back null instead of a plausible-looking guess. guess shows what the model would otherwise have picked. Clairic also works with images Here’s a real-life photo of a receipt — the text is not perfect and the angle of the image doesn’t help its legibility. We passed this image to Clairic to see what it could extract: { "model": "clairic", "answers": { "order_number": { "type": "number", "p_null": 0.0040206750854849815, "guess": 77245, "confidence": 0.776249383996532, "value": 77245 }, "purchased_at": { "type": "datetime", "p_null": 4.136094133855295e-08, "guess": "2026-07-01T13:34:00", "confidence": 0.831464227002992, "value": "2026-07-01T13:34:00" }, "quantity": { "type": "number", "p_null": 5.2313655629632194e-08, "guess": 2, "confidence": 0.9997007500403496, "value": 2 }, "unit_price": { "type": "number", "p_null": 0.001599092734977603, "guess": 7.99, "confidence": 0.9991279019989127, "value": 7.99 }, "subtotal": { "type": "number", "p_null": 9.69956488461321e-08, "guess": 15.98, "confidence": 0.9999881983893096, "value": 15.98 }, "sales_tax": { "type": "number", "p_null": 2.5511653802823275e-06, "gue [truncated for AI cost control]