CTGT выпускает инструмент с открытым исходным кодом Concordance, который помогает выяснить, почему ИИ-агенты принимают непоследовательные решения
Генеративный ИИ — невероятный шаг вперёд для бизнеса: он позволяет компаниям решать широкий круг задач, связанных с обработкой знаний, даже если входные данные постоянно меняются и не отличаются единообразием. Но как обеспечить, чтобы результаты оставались последовательными и соответствовали целям бизнеса? Это куда более сложная задача, поскольку изначально генеративный ИИ устроен так, что он «недетерминирован»: результаты формируются на лету и могут сильно различаться даже при одинаковых или похожих входных данных.
Чтобы помочь компаниям использовать эту технологию и добиться большей согласованности результатов, скрытно работающий стартап CTGT выпускает новую систему под названием Concordance по открытой лицензии Apache 2.0. Она предоставляет компаниям бесплатные инструменты для выяснения причин, по которым приложение на базе ИИ принимает разные решения при выполнении одной и той же задачи.
По данным CTGT, в выпуск входят протокол тестирования, эталонная реализация и экспериментальные данные. Компании могут использовать и изменять программное обеспечение в коммерческих целях в соответствии с лицензией; компания заявляет, что не планирует выпускать платную или размещённую в облаке версию Concordance.
Инструмент призван решить проблему, с которой CTGT столкнулась в собственном приложении для проверки соответствия требованиям: при четырёхкратной обработке одного и того же банковского руководства система выдала четыре разных набора обязательств. В одном из запусков она не включила требование передать серьёзную проблему руководителю по вопросам соответствия требованиям — хотя базовая модель отвечала одинаково каждый раз, когда получала идентичный запрос.
Для компаний, переходящих от ИИ-помощников к агентам, которые одобряют решения, отмечают проблемы или фиксируют значимые решения, Concordance предлагает способ определить, на каком этапе возникают расхождения.
«Нужно начинать с того места, где ИИ фактически принимает решение, за которое кому-то впоследствии, возможно, придётся отчитываться», — рассказал основатель и генеральный директор CTGT Сирил Горлла в интервью VentureBeat.
Почему один и тот же документ привёл к разным решениям
CTGT называет себя лабораторией прикладной интерпретируемости: она изучает поведение моделей ИИ и окружающего их программного обеспечения в таких сферах, как банковское дело и страхование. По словам Горллы, он основал компанию на базе исследований, проведённых после учёбы в UC San Diego и работы в Stanford. Коммерческое направление компании включает механизм обеспечения соблюдения политик для регулируемых предприятий; оно не связано с Concordance.
Первоначальный эксперимент проводился на собственном приложении CTGT, а не на раскрытой клиентской системе. В технической заметке подробно описано, как система обработала девятистраничное руководство для розничного банкинга с помощью Qwen3.8-27B в режиме детерминированного инференса SGLang.
В четырёх запусках было извлечено 32, 31, 33 и 33 обязательства. Совпадение итоговых чисел не означало совпадения результатов: все четыре ответа различались.
При этом модель давала согласованные ответы на все 74 идентичных запроса, которые повторялись в ходе этих запусков. Менялось то, что ей отправляло приложение.
«То есть даже если устранить недетерминированность модели, ваш конвейер всё равно может выдать четыре разных ответа», — сказал Горлла.
CTGT выявила три причины. В запросах появлялись уникальные для загрузки идентификаторы; список маршрутизации из 30 пунктов менял порядок; а реестр тем расширялся между запусками, меняя последующие запросы.
В одном сравнении различия затрагивали всего четыре строки с идентификаторами в запросе длиной 12 525 символов. Затем модель классифицировала пять правил разрешения конфликтов как справочную информацию и не включила обязательство, которое сохранилось в другом запуске.
CTGT заменила идентификаторы стабильными метками, отсортировала список и проводила каждый тест в новой организационной среде. В пяти последующих запусках каждый раз получался один и тот же набор из 34 обязательств.
Для сравнения сохранённых результатов пришлось нормализовать уникальные для загрузки идентификаторы, хотя промежуточные результаты разбора и интерпретации совпадали и без этой корректировки.
Эксперимент демонстрирует сбой в одном приложении при обработке одного документа. Он не показывает, насколько распространена эта проблема в корпоративных системах.
Что измеряет Concordance — и чего она не измеряет
Concordance анализирует как программное обеспечение, обслуживающее модель, так и приложение, которое её использует. Система фиксирует точные запросы к модели и её ответы, сравнивает результаты на последовательных этапах и определяет, где впервые возникает расхождение.
Это позволяет разделить две задачи отладки: модель по-разному отвечает на идентичные запросы или код приложения меняет сами запросы.
Исследование Thinking Machines Lab помогает объяснить первую проблему. Даже настройка генерации с минимальной случайностью не гарантирует идентичных ответов, поскольку изменения в пакетной обработке на сервере могут влиять на численные вычисления. Представители CTGT сообщили, что компания использует детерминированный режим SGLang, разработанный с опорой на это исследование.
В отдельном тесте обслуживания моделей, проведённом CTGT, Qwen3.8-27B выдала ответы, в точности совпадавшие с контрольным ответом, во всех 800 запросах при детерминированной конфигурации. Этот показатель отражает точное совпадение текста, а не правильность ответов.
Различие особенно заметно в эксперименте с соблюдением требований. При повторной отправке запроса, приведшего к неправильной классификации, ошибка повторилась восемь раз.
«Мне кажется, многие смешивают понятия: повторяемость — это не обязательно то же самое, что правильность», — сказал Горлла.
Следующей задачей измерения CTGT считает оценку того, остаются ли решения верными политикам при изменении формулировок. Представленные результаты Concordance не доказывают, что система автоматически предотвращает нарушения политик.
Могут ли модели принятия решений, такие как Jev, предотвратить эту проблему?
Появление моделей принятия решений предлагает компаниям ещё один способ снизить некоторые из этих рисков уже на этапе проектирования. Подход TypeSafe System One, реализованный в Jev, возвращает ограниченный набор вариантов, оценок и вероятностей для обработки программным обеспечением. Разработчики задают допустимые ответы, а не просят модель сгенерировать ничем не ограниченный ответ. AWS также описывает более широкую категорию моделей принятия решений, к которой относятся Jev, SemIf и Strands Decider 2B.
Рекомендуемая TypeSafe архитектура оставляет управление рабочими процессами и детерминированные бизнес-правила в коде, а ИИ использует для более узких задач оценки неструктурированной информации. В процессе проверки соответствия требованиям это может означать, что модель классифицирует конфликт, а код требует передать его на эскалацию при наличии соответствующего условия. Выполнение обязательного шага больше не будет зависеть от того, решит ли агент его выполнить. Это архитектурное следствие, а не конфигурация, проверенная CTGT.
Такой подход решает часть той же проблемы надёжности, но на другом уровне. Модель принятия решений выносит суждение; Concordance проверяет, воспроизводит ли это суждение система в целом и где начинаются расхождения. Ограничение формата ответа не позволяет выдать результат, не соответствующий схеме, но классификатор всё равно может выбрать неверный вариант из разрешённых. Если на более раннем этапе обработки документа пропущено обязательство, последующий классификатор не сможет надёжно обеспечить соблюдение правила, о котором он не знает.
Среди ограничений Jev 1.13, перечисленных самой TypeSafe, — чувствительность к порядку вариантов и трудности при работе с нерелевантным контекстом. В демонстрации самосогласованности компании сообщается, что в двух из восьми вопросов менялась метка при повторных тестах, каждый из которых включал новый идентификатор в запросе. Передача неопределённых результатов на проверку человеку повысила согласованность, однако TypeSafe прямо предупреждает, что это не делает модель детерминированной. Поскольку запросы менялись, тест не доказывает нестабильность при идентичных входных данных; он показывает, почему одного лишь постоянства смысла задачи недостаточно.
Поэтому для покупателей эти подходы могут дополнять друг друга: использовать ограниченные суждения модели и закреплённые в коде правила, чтобы уменьшить вероятность сбоев, а затем проверять весь рабочий процесс на повторяемость и точность. CTGT не предоставила сравнение Concordance с использованием Jev, поэтому доступные данные не позволяют установить, какая архитектура лучше справилась бы с банковским примером.
Как инструмент дополняет существующие средства мониторинга
Горлла позиционирует Concordance как дополнение к существующим системам трассировки, которые фиксируют этапы работы приложения на базе ИИ.
«И ничего удалять не нужно, верно? Это бесплатно. Лицензия Apache 2.0», — сказал он.
Такое позиционирование важно, поскольку конкурирующие платформы уже предлагают широкие возможности отладки.
Заявленное отличие Concordance — специальная процедура сравнения: повторить работу, сопоставить этапы и определить, вызваны ли расхождения изменениями во входных данных или в ответах. Ценность инструмента заключается в том, что он упрощает такое исследование и позволяет воспроизвести его.
CTGT не представила прямого сравнительного тестирования, доказывающего, что эти платформы не могут выявить те же сбои. Их описанные функции пересекаются с возможностями, необходимыми Concordance, что подкрепляет аргумент Горллы в пользу совместного использования инструментов.
Горлла также рассказал о неназванной консалтинговой фирме, которая обнаружила ранее пропущенные ложноположительные результаты с помощью прежней разработки CTGT — системы LineageEval. Этот пример относится к другому инструменту и не подтверждает результаты использования Concordance клиентами.
С чего начать компаниям
Горлла рекомендует в первую очередь проверять решения, имеющие операционные последствия, включая одобрения, отметки о проблемах, обязательства по соблюдению требований и страховые выплаты. Для помощника, составляющего черновики, которые затем проверяет человек, приоритеты тестирования будут отличаться от приоритетов для агента, чьи результаты становятся официальной записью компании.
«Не нужно постоянно отслеживать всё подряд. Нужно лишь уметь повторно воспроизвести любое решение и получить тот же ответ, верно?» — сказал он.
Он рекомендует сохранять полные запросы и ответы для вызовов модели, приводящих к принятию решений. Командам следует повторять тесты при изменении моделей, запросов или исходных документов, а также поддерживать набор проверенных примеров с заранее известными ожидаемыми результатами, чтобы отслеживать ухудшение поведения системы.
По словам Горллы, этот подход не требует доступа к внутренним рассуждениям модели. Компании, использующие закрытые API, могут сравнивать входные данные, ответы и решения, а доступ к весам модели позволяет глубже исследовать причины сбоя.
Для покупателей выбор модели, проектирование рабочего процесса, тестирование воспроизводимости и обеспечение соблюдения политик помогают справляться с разными типами сбоев. Модели принятия решений могут ограничивать отдельные суждения, код — обеспечивать выполнение обязательных действий, а Concordance — помогать находить расхождения в рамках всего рабочего процесса. Компаниям по-прежнему нужны независимые проверки на соответствие политикам, чтобы установить, верно ли повторяемое решение.
CTGT направляет разработчиков на страницу исследования Concordance. Использованное в эксперименте проприетарное приложение для проверки соответствия требованиям не входит в выпуск с открытым исходным кодом. Компаниям, внедряющим эти инструменты, всё равно потребуется интегрировать их в свои рабочие процессы и учесть затраты на вызовы моделей, хранение данных и инженерные работы, необходимые для тестирования.
