Мой блог
Модели System One: разделение быстрого суждения и медленного рассуждения у ИИ
Современные ИИ-агенты задействуют языковые модели практически для каждого шага: от выбора инструментов до генерации ответов. Подход гибкий, но дорогой, особенно когда масштабируются простые бинарные решения. Как отмечает Сергей Багров, концепция разделения задач на ограниченные суждения и генеративное рассуждение меняет привычный подход к проектированию архитектуры агентов.
Идея заключается в том, что агенту не нужна универсальная высокоуровневая логика в каждой точке выполнения процесса. Вместо этого можно распределить роли между узкоспециализированными моделями оценок и генеративными языковыми сетями общего назначения.

Что на практике делают модели System One
Компания TypeSafe представила линейку таких моделей, выпустив первую из них в сентябре 2026 года. Инструменты этого класса не пишут развернутый текст. Вместо этого разработчик передает в модель текущее состояние — например, данные пользователя и текст обращения в поддержку — вместе с набором вопросов, имеющих заранее определенные типы ответов. В ответ система возвращает типизированные значения и вероятности.
Согласно официальной документации разработчиков, для вынесения вердиктов используются три базовых примитива:
- Choice — выбор одного варианта из заранее заданного списка опций.
- Score — оценка объекта по упорядоченной шкале.
- Noul — оценка вероятности истинности конкретного утверждения.
В рамках одного запроса разрешено задавать несколько независимых вопросов относительно одного и того же состояния системы. Например, при обработке пользовательской жалобы алгоритм может одновременно определять ответственный отдел, требуемую срочность ответа и факт запроса возврата средств.
Архитектурный сдвиг важнее конкретной модели
Дискуссии вокруг ИИ часто сводятся к противостоянию крупных и компактных моделей, однако новые подходы предлагают принципиально иную границу разделения обязанностей. Часть этапов по-прежнему требует генерации текста, в то время как другие задачи сводятся к узким оценкам, которые легко обрабатываются программным кодом.
Такой подход формирует отдельный слой принятия решений внутри агента. Модель вычисляет вероятности, а программное обеспечение применяет бизнес-политики. Если расчетная вероятность превышает проверенный порог, а само действие является обратимым и безопасным, рабочий процесс продолжается автоматически. При возникновении неопределенности или риска подключение человека остается обязательным.
Существуют параллели с динамической маршрутизацией запросов, однако разница принципиальна. Инструменты вроде RouteLLM выбирают между сильной и слабой языковой моделью для баланса цены и качества. Модели класса System One выдают строго ограниченные суждения, которые код приложения может использовать напрямую для маршрутизации и логики.
Почему агентные циклы идеально подходят для таких моделей
Архитектура автономных агентов предполагает выполнение множества мелких проверок до получения финального результата. Агенту приходится постоянно решать, какие инструменты задействовать, ранжировать найденные документы, оценивать риски и проверять достаточность собранных доказательств.

Интеграция подобных решений в связке с фреймворками вроде LangChain позволяет выполнять проверки вызовов инструментов и маршрутизацию на периферии, пока генеративная модель продолжает заниматься планированием. Параллелизация вопросов также упрощает декомпозицию задач: разработчики могут разбивать размытые инструкции на набор дискретных проверочных вопросов, сокращая общую цепочку вызовов.
Тем не менее, универсальные языковые модели остаются незаменимыми, когда требуется одновременно сформировать решение и развернутое объяснение к нему. Эффективность узких моделей суждений напрямую зависит от снижения общей задержки системы, точности оценки вероятностей и стабильности работы при различных входных данных.
Гарантирует ли типизация корректность
Поскольку формат выходных данных задан заранее, модель не может вернуть случайное поле или неструктурированный текст. Это исключает один из классов сбоев, но не защищает от семантических ошибок. Система способна выдать неверный отдел или присвоить ошибочный уровень риска, действуя при этом полностью в рамках строгой типизации.
Документация разработчиков подчеркивает важный нюанс: калибровка оценивается по группам предсказаний и не гарантирует безошибочность конкретного отдельного прогноза. Командам необходимо самостоятельно тестировать соответствие прогнозируемых вероятностей реальным результатам на своих рабочих данных.
Первые данные о производительности
Первые тесты демонстрируют время отклика от 70 до 500 миллисекунд, а также заметное снижение затрат в изолированных внутренних сценариях. Тем не менее, реальные показатели на промышленных нагрузках еще предстоит подтвердить независимыми испытаниями.
Практическая проверка перед внедрением
При создании первого рабочего процесса на базе таких решений не стоит сразу автоматизировать критически важные задачи вроде медицинских одобрений или блокировок аккаунтов. Лучше начать с частых, обратимых и легко проверяемых процедур: маршрутизации тикетов, классификации документов или контроля качества.
Для оценки применимости подхода ответьте на четыре ключевых вопроса:
- Ограничен ли набор возможных ответов конечным числом вариантов?
- Можете ли вы четко сформулировать критерии для оценки?
- Существуют ли измеримые метрики успешности?
- Есть ли у вас резервный план на случай сбоя автоматики?
Анализ должен охватывать весь пайплайн целиком, включая точность решений, частоту эскалаций, задержки и стоимость обработки одной задачи. Тестирование следует проводить в неблагоприятных условиях с нестабильными формулировками и недостающими данными.
Долгосрочные выводы для разработчиков
Независимо от эволюции конкретных продуктов, архитектурный вопрос остается открытым: действительно ли каждое машинное решение должно выражаться через генерацию естественного языка? Во многих производственных сценариях ответ отрицательный. Генеративные модели могут отвечать за планы и интерпретации, а специализированные классификаторы — за оценку и маршрутизацию под управлением жесткого программного кода.
