d1-ultra

d1-ultra — модель принятия решений Liquid AI, представленная 15 октября 2026 года. Она принимает текст, изображения или их сочетание и отвечает на заранее сформулированные вопросы распределением вероятностей, не генерируя последовательность выходных токенов. Такой формат рассчитан на задачи классификации и проверки: определить, присутствует ли дефект, выбрать подходящую категорию или сопоставить изображение с условием. Это не обычный чат-бот и не универсальный генератор объяснений.

Liquid AI приводит пример промышленного контроля: модель может оценивать фото платы относительно спецификации; другой сценарий — сопоставить повреждение на снимке с описанием страхового обращения. Эти примеры показывают тип задачи, а не гарантированную точность на произвольной камере, документе или русском тексте. Перед использованием надо собрать примеры из собственного процесса: качество освещения, угол, мелкие детали, формулировки сотрудников и доля неоднозначных случаев существенно влияют на результат.

Компания указывает цену $0,042 за миллион входных токенов и сообщает, что выходные токены не тарифицируются отдельно, поскольку ответом служат вероятности. Изображения переводятся во входные токены; опубликованный пример для картинки 1024×1024 — 1536 токенов. Каждый вопрос считается отдельным запросом, в том числе его текст и переданное изображение. Поэтому при нескольких проверках одной фотографии расход нужно считать по каждой операции, а не умножать одну загрузку на тариф один раз.

Модель доступна через Liquid API. Анонс не обещает универсального локального запуска открытых весов, поэтому проверьте требования к сервису, доступности из страны, хранению запросов, договорным условиям и удалению данных. Если используются изображения клиентов, работников, медицинских случаев или коммерческой продукции, предварительно определите правовое основание и минимизируйте отправляемые сведения. Не загружайте документы с персональными данными в тест ради удобства.

Вероятность не равна объяснению. Ответ 0,87 может быть полезен для сортировки потока, но без оценки калибровки нельзя считать, что 87% аналогичных случаев будут верны. Измерьте ложные срабатывания и пропуски отдельно, особенно если цена ошибок различается. Например, для контроля дефектов пропущенный брак может быть дороже, чем лишняя ручная проверка. Включите класс «неопределённо» либо отдельную очередь для случаев вне обучающего распределения.

Для оценки разделите данные на настройку порога и финальный тест. Зафиксируйте разметку до запуска, проверьте согласие экспертов и запишите версию API. Измеряйте точность по каждому классу, полноту обнаружения, калибровку и задержку; затем пересчитайте стоимость одного обработанного объекта с учётом всех вопросов и повторов. Сравните результат с простым правилом, OCR или ручной сортировкой. Если модель добавляет расходы, но не снимает проверяемую работу, внедрение не оправдано.

Используйте результат только на том этапе, где ошибку можно безопасно остановить. Классификатор может предложить очередь или пометку, но не должен один отказывать человеку в выплате, блокировать услугу или принимать решение о найме. Вероятностный выход помогает выбрать следующий шаг, но владелец процесса задаёт порог, проверяет последствия и пересматривает его после смены данных. Отличие от генеративного подхода объяснено в [сравнении с Beam](/article/sravnenie-beam-d1-ultra-generaciya-i-klassifikaciya-20261017-b1/); обзор сценариев находится в [отдельной статье о d1-ultra](/article/obzor-liquid-d1-ultra-resheniya-po-foto-20261017-b1/).

Редакционная оценка: d1-ultra стоит тестировать там, где вход и варианты ответа заранее ограничены, а решение можно перепроверить. Основной риск — принять уверенное число за объяснимое доказательство. До пилота определите порог, стоимость ошибок, правила хранения изображений и процедуру ручного разбора. Без этого краткий выход лишь сделает ошибку менее заметной.

Перед подключением к очереди проверьте внеплановые входы: пустое изображение, необычный формат, текст на нескольких языках, частично закрытый объект и вопрос, который не относится к предусмотренным категориям. Зафиксируйте, как API сообщает об ошибке и что получает вызывающая система. Не превращайте отсутствие ответа или сетевой тайм-аут в положительную метку. Если сервис недоступен, запись должна переходить в безопасную ручную очередь, а не автоматически считаться проверенной.

Отдельно проверьте, насколько модель переносит изменение условий: новая партия товара, другая камера, сезонный свет, сжатие снимка или незнакомый формат заявки. Для каждого варианта сохраните долю правильных ответов и долю случаев, которые система честно пометила неопределёнными. Если качество падает только на одном типе входа, сузьте область применения или добавьте ручную проверку именно для него. Перепроверяйте набор после обновления API и не смешивайте результаты разных версий в одной таблице. Такой журнал позволит понять не только среднюю точность, но и где автоматизация перестаёт быть надёжной.