Темы



Представляем Clairic — новый класс моделей извлечения данных System One

Коротко сгенерировано ИИ по тексту статьи
  • Cloudflare открыла предварительный доступ к Clairic в Workers AI под идентификатором @cf/cloudflare/clairic; открытые веса планируют выпустить вскоре.
  • За один проход модель извлекает и вычисляет типизированные значения, оценки и прогнозы по неструктурированным данным; ответы обычно приходят менее чем за секунду.
  • Ответы включают значения или null, смещения найденных фрагментов и оценки уверенности; за выходные токены плата не взимается.

Почему это важно: Clairic предназначена для типичных запросов на извлечение данных, в которых LLM, по словам автора, работает неэффективно.

Сегодня мы объявляем о предварительном запуске нового класса моделей в стиле System One — моделей для извлечения данных. Наша первая модель, Clairic, доступна в Workers AI как @cf/cloudflare/clairic.Мы планируем вскоре выпустить модель с открытыми весами. Clairic — это модель для извлечения данных, которая умеет извлекать, вычислять, оценивать и прогнозировать значения по неструктурированным входным данным — и делает это со значительно более высокой точностью, меньшей задержкой и меньшими затратами, чем традиционные LLM.

Контекст

Когда месяц назад TypeSafe объявила о моделях System One, это произвело настоящий фурор в отрасли. Как пишет TypeSafe в своём блоге и объясняет Даниэль Канеман в книге «Думай медленно… решай быстро», модель System One должна быть быстрой и точной. Этим она отличается от модели System Two, способной к обдуманным рассуждениям, например LLM. Тогда TypeSafe представила Jev — модель, созданную специально для конкретного сценария использования и доступную по цене, несмотря на узкую специализацию. Она справлялась с задачами, в которых LLM не преуспевали, помогая пользователям принимать решения на основе вероятностей и данных с чётко заданными типами. Появление Jev заставило многих задуматься о новом классе моделей, не относящихся к LLM, и о том, как встроить их в рабочие процессы.

Нас вдохновила концепция моделей System One, и мы задумались о других задачах, в которых LLM работают неэффективно. Сегодня фронтирным LLM снова и снова отправляют структурированные запросы на получение данных одного и того же вида: Какова итоговая сумма в счёте? Когда доставили заказ? На сколько дней задержали доставку? Сколько будет стоить ремонт? Каким будет трафик в следующие 24 часа? Ни на один из этих вопросов нельзя заранее составить список ответов —, а это необходимо, чтобы модель принятия решений могла оценить вероятности. Так мы пришли к классу моделей, который представляем сегодня: моделям извлечения данных System One.

Представляем модели извлечения данных System One

До сих пор все модели System One были моделями принятия решений: Jev и Clef принимают исходное состояние и список вопросов, а затем оценивают вероятности для входных данных и перечисленных вами вопросов. Clairic — первая модель нового класса: модель извлечения данных System One. Она по-прежнему быстрая, типизированная и недорогая, но в ответ выдаёт непосредственно значения, извлечённые из входных данных, вычисленные на их основе или спрогнозированные.

Большинство задач для моделей предполагают один из трёх типов результата: число, выбор из фиксированного набора или текст в свободной форме. Clairic справляется с первым типом, возвращая числа с диапазоном 80%, а также извлекает из входных данных типизированные значения, например имена, даты и списки. Clef работает со вторым типом: выбирает один из вариантов и возвращает вероятность для каждого. LLM справляются с третьим. Мы называем Clairic и Clef моделями System One, потому что они отвечают за один проход, не рассуждая и не генерируя токены. Оплата взимается только за входные данные, а ответы обычно поступают менее чем за секунду. LLM, которой нужно рассуждать над той же задачей, потребовалось бы несколько секунд.

Модель извлечения данных может возвращать:

  • Извлечённые значения: текст, скопированный из входных данных, например имя, идентификатор заказа или описание. Каждое значение возвращается как фрагмент текста с символьными смещениями и оценкой уверенности.
  • В том числе вычисленные значения: числа, даты, время, дату и время, длительность и списки, считанные из входных данных или вычисленные на их основе. Они соответствуют правилам своего типа (например, для центов указываются два знака после запятой) и сопровождаются оценкой уверенности.
  • Оценочные значения: значения, не указанные во входных данных напрямую, но подтверждаемые ими. Каждое из них возвращается в виде распределения в заданных вами границах и с указанным шагом, с медианой и 80-процентным интервалом.
  • Прогнозируемые значения: будущие значения временного ряда — по одной оценке на каждый следующий шаг, каждая со своим 80-процентным интервалом.

Кроме того, поскольку модель не генерирует токены, она не может допустить опечатку в ответе или «галлюцинировать» так же, как LLM (хотя, разумеется, она может ошибаться). Результат — это значение запрошенного типа или null, если модель не смогла найти ответ во входных данных. К результатам также прилагаются оценки уверенности, которые помогут понять, стоит ли доверять модели или лучше перепроверить ответ.

Вот как модели извлечения данных вписываются в систему моделей System One и System Two:

System One: извлечение

System One: принятие решений

System Two

Примеры моделей

Clairic

Jev, Clef

GPT, Claude, Gemini, DeepSeek

Выборка

Один параллельный проход

Один параллельный проход

По одному токену за раз

Назначение

Прогнозировать значения

Принимать решения

Писать и рассуждать

Подход в машинном обучении

Регрессия и извлечение

Классификация

Генерация

Режим мышления

System 1: быстро, за один проход

System 1: быстро, за один проход

System 2: медленно, обдуманно

Результат

Типизированные значения: фрагменты текста, числа, даты, время, списки, распределения с калиброванными вероятностями

Типизированные решения: варианты с калиброванными вероятностями

Текст в свободной форме

Непрерывное, но типизированное и ограниченное вашей схемой

Конечный набор вариантов, заданный вами

Любой результат

На какие вопросы отвечает

Какова сумма? Когда это произойдёт? Сколько это будет стоить?

К какой категории это относится? Это законно? Какое действие следует предпринять?

Почему это произошло? Как нам к этому подступиться? Можешь это исправить?

Результат всегда имеет допустимый формат?

Да: каждый ответ — значение объявленного типа (или null), не выходящее за заданные вами границы

Да: ответы всегда представляют собой один из предложенных вами вариантов

Нет: строки нужно разбирать и проверять

Вместе эти модели помогают эффективнее разбирать реальные данные, принимать решения на их основе и затем действовать. Модели извлечения преобразуют исходные данные в типизированные значения, модели принятия решений превращают значения в решения, а LLM — решения в слова.

Как работает запрос

Clairic устроена иначе, чем LLM. Как и модель принятия решений, она обрабатывает только входные токены за один прямой проход, поэтому за выходные токены плата не взимается. В некоторых сценариях она значительно быстрее, дешевле и точнее LLM.

Запрос состоит из state (текста для анализа и до четырёх необязательных изображений) и набора типизированных fields. Вы задаёте имя каждого поля, указываете его тип и, при желании, описание на обычном языке instructions, а затем получаете по одному типизированному ответу на каждое поле — всё за один параллельный проход. Рассуждений и выходных токенов нет: все вычисления выполняются за один прямой проход, поэтому это быстро и дёшево.

Тип

Возвращаемый результат

text

Конкретный фрагмент входных данных с указанием его смещений

number

Считанное или вычисленное число с учётом integer и decimals

date, time, datetime

Календарные даты и допустимое время в формате ISO

duration

Длительность в выбранной вами единице измерения

list

Подходящий текст, число или дата в порядке следования во входных данных

estimate

Распределение в пределах [min, max], на вашей сетке step, с линейной или логарифмической шкалой.

forecast

Одна оценка для каждого будущего шага временного ряда

Каждый скалярный ответ сопровождается p_null (вероятностью того, что значение отсутствует во входных данных) и confidence. Каждый ответ estimate включает медиану и 80-процентный интервал (от p10 до p90), а по запросу — все 99 перцентилей. Количество полей не ограничено: если они не помещаются вместе с входными данными в один проход, сервер разбивает их на несколько параллельных проходов, в каждом из которых обрабатываются все входные данные, а затем объединяет ответы.

Вот несколько примеров, которые иллюстрируют возможности модели. Разумеется, для использования этих возможностей в рабочем процессе понадобятся подходящие входные данные.

Пример: извлечение значений

Сегодня извлечение данных, вероятно, самая распространённая задача, которую поручают LLM: «верни номер счёта, поставщика и срок оплаты в формате JSON». Обычно это работает, но ошибки трудно обнаружить. Результат может оказаться невалидным JSON, цифра может быть прочитана неверно при генерации, а когда модель возвращает текстовый фрагмент, уже нельзя определить, где именно он встречался в исходном документе. Чтобы решить эту проблему, многие создают конвейеры извлечения данных с несколькими уровнями разбора и проверки схемы, повторными попытками и выборочными проверками. Кроме того, за каждый параметр каждого документа приходится платить за рассуждения и выходные токены.

Clairic работает иначе: она не генерирует текстовые ответы. Вместо этого вы получаете:

  • Значения, извлечённые из входных данных, поэтому ответ опирается на исходный материал.
  • Вычисленные значения, благодаря чему модель может разбирать неструктурированные данные без предварительной очистки.
  • Фрагменты с символьными смещениями, позволяющие указать, где именно во входных данных находилась информация.
  • Метки уверенности, которые помогают определить, какие значения требуют дополнительной проверки.
  • Строго типизированный результат, поэтому числа и даты формируются в соответствии с правилами своего типа (например, поле для центов содержит два знака после запятой).
  • Обработку нулевых значений: для отсутствующего поля возвращается null в качестве ответа (вместе с оценочной вероятностью нулевого значения и предположением).
  • Более дешёвые и быстрые ответы, поскольку все поля обрабатываются за один и тот же параллельный проход. Поэтому запрос на тридцать полей стоит примерно столько же, сколько запрос на три.

Рассмотрим пример, который покажет, как Clairic извлекает значения из неструктурированных данных и формирует оценки. Возьмём письмо в службу поддержки:

Здравствуйте! Заказ A-88412 доставили 28 сентября 2026 года: экран треснул, а на углу появилась вмятина. Я заплатил 649,00 доллара плюс 52,10 доллара налога. Сейчас 9 октября 2026 года, и я хотел бы отремонтировать товар или получить возврат денег. Спасибо, Дана

Из Worker вы отправите Clairic запрос на обработку этих данных:

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 возвращает извлечённые значения, фрагменты текста с указанием их положения во входных данных, вероятность того, что значение равно null (p_null), и оценку уверенности:

{
  "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
  }
}

Обратите внимание на несколько деталей:

  • amount_paid нигде в письме не указано. В этом примере Clairic сложила стоимость товара и налог за один проход и вернула сумму.
  • days_since_delivery также вычислено на основе двух дат в тексте, а не указано напрямую во входных данных.
  • damage содержит оба вида повреждений в виде точных текстовых фрагментов, поэтому их можно выделить в исходном тексте.
  • tracking_number в письме отсутствует, поэтому модель возвращает null, а не правдоподобное предположение. guess показывает, какой вариант модель выбрала бы в противном случае.

Clairic также работает с изображениями

Вот реальная фотография чека: текст не идеален, а угол съёмки не способствует хорошей читаемости. Мы передали это изображение Clairic, чтобы проверить, что удастся извлечь:

{
  "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,
    "guess": 0,
    "confidence": 0.9999800924450729,
    "value": 0
   },
   "tip": {
    "type": "number",
    "p_null": 5.953857908025384e-05,
    "guess": 2.39,
    "confidence": 0.9335768781214697,
    "value": 2.39
   },
   "discount": {
    "type": "number",
    "p_null": 0.9994148015975952,
    "guess": 0,
    "confidence": 0.91852733929319,
    "value": null
   }
  }
}

Как видно, модель смогла извлечь из изображения все значения и сопроводить их оценками уверенности. Она также правильно указала, что на чеке не было скидки, вернув null.

Пример: оценка значений

Некоторые значения вообще отсутствуют во входных данных, однако те содержат сведения, на основе которых их можно оценить. Например, нужные значения могут быть не указаны прямо, но их можно вывести из соседних значений. Если попросить LLM дать оценку, обычно она выдаёт одно число, не показывая, насколько уверена в нём. Модель может сделать осторожное предположение, «галлюцинировать» или прийти к ответу путём рассуждений. Если в итоге вы получаете оценку, последующие этапы обработки не могут отличить уверенные 180 долларов от неуверенных 180 долларов, а значит, не помогут решить, что в данной ситуации можно автоматизировать. Кроме того, рассуждения с помощью LLM обходятся намного дороже и занимают гораздо больше времени.

Модель принятия решений может приблизительно оценить значение, выбрав одну из категорий («меньше 100 долларов»,»100–500 долларов» и т. д.), но категории дают слишком грубую оценку, каждая из них увеличивает число входных токенов, а добавление новых категорий создаёт дополнительные поводы для ошибок при принятии решения.

Clairic возвращает распределение в заданном вами диапазоне: конкретное значение, медиану, 80-процентный интервал и все перцентили по запросу. Оценка гарантированно находится в заданных границах, поэтому впоследствии не нужно ничего ограничивать или округлять. Ширина интервала отражает уверенность, основанную на данных: узкий диапазон означает высокую уверенность, широкий — низкую. Эту информацию можно использовать, чтобы направить результат на дополнительную проверку.

Вот ещё один пример: Clairic анализирует исторические цены на жильё и сопоставимые продажи, чтобы определить оценочную стоимость:

const { answers } = await env.AI.run("@cf/cloudflare/clairic", {
  state: `Comparable sales:
sqft,beds,year_built,neighborhood,sale_price
1450,3,1998,Elm Park,412000
2100,4,2006,Elm Park,585000
980,2,1975,Riverside,265000
1600,3,2003,Elm Park,449000
1300,3,1990,Riverside,318000

Subject property:
sqft,beds,year_built,neighborhood
1620,3,2001,Elm Park`,
  fields: {
    sale_price:     { type: "estimate", unit: "USD", min: 50000, max: 5000000, scale: "log", step: 1000 }
});

Clairic вернёт оценочное значение:

{
  "sale_price":     { "type": "estimate", "value": 418000, "median": 415000, "p10": 370000, "p90": 470000, "p_below": 0.0, "p_above": 0.0 }
}

Значения всегда находятся в заданных вами границах, а ширина интервала показывает, насколько входные данные влияют на прогноз: диапазон цены узкий (370 000–470 000 долларов), а диапазон срока продажи — широкий (24–148 дней). Количество полей не ограничено, и ответы формируются параллельно, поэтому за один запрос можно оценить множество объектов (по одной оценке на каждый объект, потенциального клиента или объявление), а затем отсортировать результаты в коде.

Пример: прогнозирование значений

Обобщённым моделям довольно сложно прогнозировать значения временных рядов. Обычно приходится либо создавать отдельный конвейер для каждой метрики (разбирать данные, обучать модель, настраивать и развёртывать её), либо загружать в LLM данные за 36 месяцев и просить спрогнозировать следующие три. Первый подход точен, но для каждого нового ряда его настройка обходится очень дорого и требует много времени. Второй прост в реализации, но выдаёт точечные прогнозы без интервалов; прогнозы меняются в зависимости от формулировки запроса, а уверенность в ответах невелика.

Clairic занимает промежуточное положение: она не претендует на замену специализированной модели временных рядов, но работает немного быстрее и дешевле обычной LLM. Поле forecast принимает историю в виде обычного текста в формате state и возвращает значение и 80-процентный интервал для каждого следующего шага в заданных вами границах. Модель анализирует историю в том виде, в каком вы её уже храните, будь то экспорт CSV, скопированная панель мониторинга или строки с примечаниями, и зачастую может работать без предварительной очистки данных.

Чтобы проверить, как это работает на реальных данных, мы взяли общедоступный временной ряд: количество людей, которых Управление транспортной безопасности США (TSA) ежедневно проверяет на контрольно-пропускных пунктах в аэропортах страны. В течение 21 дня подряд каждое утро мы просили Clairic спрогнозировать число пассажиров на следующий день, используя фактические данные за прошедшие дни:

const { answers } = await env.AI.run("@cf/cloudflare/clairic", {
  state: `Daily number of people screened at TSA checkpoints at US airports.
date,weekday,travelers
2026-07-16,Thu,2850229
...
2026-10-13,Tue,2353356
Forecast date: 2026-10-14 (Wed)`,
  fields: {
    travelers: { type: "forecast", horizon: 1, interval: "day",
                 min: 500000, max: 4000000, scale: "log",
                 instructions: "Number of people screened tomorrow" },
  },
});

Результат:

{
  "travelers": { "type": "forecast", "value": [2416117], "median": [2419283], "p10": [2270774], "p90": [2556769] }
}

Фактически в тот день TSA проверило 2 419 474 человека — почти столько же, сколько медианное значение 2 419 283, спрогнозированное Clairic.

Источник данных: данные TSA о пассажиропотоке на контрольно-пропускных пунктах, получены 15 октября 2026 года.

За 21 день средняя ошибка прогнозов Clairic составила 3,3%, а фактические показатели за 17 из 21 дня попали в её 80-процентный интервал — именно так и должен работать интервал такого уровня. Модель выявила недельную закономерность, опираясь только на числа: по вторникам и субботам пассажиров было меньше, а по четвергам, пятницам и воскресеньям — больше.

Интересны и промахи: три из четырёх дней, когда фактические значения вышли за границы интервала, пришлись на выходные в честь Дня Колумба, когда самолётами воспользовалось больше людей, чем можно было предположить по данным предыдущих недель. Clairic строит прогнозы на основе закономерностей временного ряда, но не учитывает события, которых в нём не отражено, например праздники.

Думать быстро и медленно

Эти модели созданы для интеграции в существующие агентные рабочие процессы. Модель извлечения данных прогнозирует значения, модель принятия решений решает, что с ними делать, а LLM предпринимает действия на их основе. Это идеальное сочетание моделей System One и System Two. Оно устраняет существующий разрыв: прежде приходилось либо вручную извлекать данные для LLM, либо поручать LLM разбор неструктурированных данных — это дорого, долго и чревато галлюцинациями. С моделями извлечения данных System One можно быстрее, эффективнее и точнее работать с данными из реального мира.

Вот пример с упомянутой ранее жалобой на повреждённый товар, который показывает, как модели могут работать вместе. Мы создали интерактивную демонстрацию, которую можно попробовать здесь.

// 1. Clairic turns the email into values
const facts = (await env.AI.run("@cf/cloudflare/clairic", {
  state: email,
  fields: {
    customer_name:       { type: "text", instructions: "Customer's first name" },
    order_id:            { type: "text", instructions: "Order number" },
    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" },
    repair_cost:         { type: "estimate", unit: "USD", min: 10, max: 5000, scale: "log", step: 1,
                           instructions: "Cost to repair the damage described" },
  },
})).answers;
const { customer_name, order_id, amount_paid, days_since_delivery, damage, repair_cost } = facts;

// 2. Clef decides from Clairic's values and the policy, not from the raw email
const options = {
  refund:  "Full refund of the amount paid",
  repair:  "Free repair, with a prepaid shipping label",
};
const { choice } = (await env.AI.run("@cf/cloudflare/clef", {
  state: `Damage claim for order ${order_id.value}.
Paid: $${amount_paid.value.toFixed(2)}. Delivered ${days_since_delivery.value} days ago.
Damage reported: ${damage.value.join(", ")}.
Estimated repair cost: $${repair_cost.median} (80% range $${repair_cost.p10}-$${repair_cost.p90}).
Policy: refunds within 30 days of delivery. Prefer repair when it costs less than 60% of the price and the damage doesn't stop the product from working.`,
  questions: {
    resolution: { type: "choice", instructions: "What should we offer?", criteria: options },
  },
})).answers.resolution;

// 3. An LLM writes the reply, from the decision and the facts it needs
const { response } = await env.AI.run("@cf/zai-org/glm-5.3", {
  messages: [{
    role: "user",
    content: `Write a short, warm reply to ${customer_name.value}. Use only these facts: order ${order_id.value}; ` +
             `damage: ${damage.value.join(", ")}; what happens next: ${options[choice]}. Under 60 words.`,
  }],
});

На каждом следующем шаге входные данные становятся чище. Clef принимает решение на основе краткого резюме из пяти строк с типизированными значениями, а не письма в свободной форме, которое также может быть уязвимо для промпт-инъекций. LLM не видит самого письма — только решение и необходимые ей прогнозы, поэтому у неё меньше чисел, которыми она может неправильно распорядиться. Каждый этап типизирован и поддаётся аудиту, а текст генерируется только на одном этапе. В версии этого конвейера, построенной исключительно на LLM, все три этапа представляют собой генеративные запросы, и каждое значение в ответе приходится проверять вручную.

Мы сравнили этот конвейер с вариантом, полностью построенным на LLM; в обоих случаях ответ составляла GLM-5.3. В версии на одних LLM модель GLM-5.3 также извлекала данные и принимала решение, используя то же письмо, ту же политику и те же запросы:

Clairic → Clef → GLM-5.3

GLM-5.3 на каждом этапе

Общая задержка

19,3 с

61,7 с

1. Извлечение данных

Clairic: 0,46 с

GLM-5.3: 16,1 с

2. Принятие решения

Clef: 0,22 с

GLM-5.3: 21,9 с

3. Ответ

GLM-5.3: 18,6 с

GLM-5.3: 16,4 с

Входные токены

701 (184 доллара за миллион обращений)

390 (546 долларов за миллион обращений)

Выходные токены

1 329 (5 848 долларов за миллион обращений)

2 544 (11 194 доллара за миллион обращений)

Стоимость миллиона обращений

6 032 доллара

11 740 долларов

Каскадный конвейер завершил работу за 19,3 секунды против 61,7 секунды: на 69% меньше времени, то есть примерно в 3,2 раза быстрее. Clairic и Clef вместе выполнили извлечение данных и приняли решение менее чем за секунду, тогда как GLM-5.3 потратил на те же два шага 38 секунд. Кроме того, использование каскадного конвейера на 49% дешевле, чем конвейера, целиком построенного на LLM. При использовании GLM оба конвейера правильно определяли факты и принимали решение в каждом запуске, но оценка стоимости ремонта от Clairic каждый раз была одинаковой, тогда как у GLM-5.3 она менялась при каждом запуске (250, 250 и 220 долларов, каждый раз с разными диапазонами).

Примечательно, что в конвейере, целиком построенном на LLM, и Gemma 4, и Qwen не справились с этой задачей: они не смогли вывести из входных данных такие значения, как repair_cost. Это показывает, что LLM не слишком хорошо справляются с извлечением данных.

Предварительная версия

Сегодня мы запускаем размещённую конечную точку Clairic на Workers AI. Вскоре мы планируем выпустить модель с открытыми весами. Сначала мы хотели рассказать о концепции модели извлечения System One, чтобы вы могли начать обдумывать, в каких рабочих процессах уместно использовать модели этого класса.

Текущая версия конечной точки — ранний чекпойнт, и мы рассчитываем, что модель станет лучше. Вот наши первые впечатления:

  • С чтением модель справляется хорошо, но многошаговая арифметика пока ей не даётся. Одно- и двухшаговые вычисления (суммы, разности, преобразования, вычисления с датами) выглядят надёжными. Длинные цепочки зависимых шагов трудно выполнить любой модели за один проход без черновика. То же касается агрегирования данных по множеству строк таблицы. По крайней мере пока лучше просить Clairic предсказать значение, а вычисления поручать коду.
  • Для оценок нужны доказательства. Лучше всего Clairic оценивает значения на основе сопоставимых примеров, истории или описательного текста во входных данных. Если запросить значение, для которого у модели нет подтверждений, точность оценки может быть ограничена.
  • Калибровка измеряется, но не гарантируется. Интервалы обучены быть откалиброванными и показывают хорошие результаты на большинстве отложенных наборов данных, но для незнакомых данных они могут оказаться слишком узкими.
  • Прогнозирование пока базовое. Модель не предназначена для точной замены моделей временных рядов, обученных на конкретных данных, или для прогнозирования с их помощью. Используйте её там, где это уместно: например, для некритичного поиска общих закономерностей, но не для подробного долгосрочного прогнозирования.
  • Учитывайте уверенность модели. Архитектура гарантирует, что каждый ответ будет правильно сформулирован, но не обязательно верным. Используйте confidence, p_null и интервалы, чтобы решать, какие задачи автоматизировать (в подходящем контексте рабочего процесса), а какие отправлять на дополнительную проверку.

С каждым новым чекпойнтом мы будем продолжать совершенствовать арифметические вычисления, оценивание и прогнозирование. После дальнейшей доработки мы также планируем выпустить модель с открытыми весами, чтобы все желающие могли с ней поэкспериментировать.

Попробуйте сами

Clairic доступна в предварительной версии на Workers AI как @cf/cloudflare/clairic. Вызывайте её из Worker с помощью env.AI.run() или откуда угодно через REST API. Полную документацию по модели можно найти здесь, а также ознакомиться с новым пояснением в документации о том, как устроен API модели извлечения.

P.S. Раз вам понравилось происхождение названия Clef, расскажем, как мы придумали название Clairic. Мы хотели, чтобы название модели было тематически и фонетически похоже на Clef. Нам пришло в голову Clair: в нём есть тот же звук «cl», а ещё оно связано с музыкой («Clair de Lune»). Но важнее было, чтобы название отражало суть модели. Clairic должна помогать с канцелярскими задачами — например, ясно извлекать данные из набора входных данных и обеспечивать точность в таких задачах, как ведение бухгалтерского учёта. А способность модели делать прогнозы перекликается с корнем »Clair» — она позволяет оценивать и предсказывать будущие значения, подобно ясновидению. Наконец, нам понравилась идея, что это регрессионная модель Cloudflare на базе ИИ. Так на свет появилась Clairic. Надеемся, она вам понравится.

© Cloudflare Blog