Обновить

От предложений LLM к управляемому исполнению: опыт разработки AI‑агента

Уровень сложностиСредний
Время на прочтение15 мин
Охват и читатели9.2K
Всего голосов 2: ↑1 и ↓10
Комментарии2

Комментарии 2

Пункт 3.5, на мой взгляд, самый ценный. «Правильное действие при неточном объяснении» — это ровно та причина, по которой мониторинг chain-of-thought нельзя считать валидацией. Модель может прийти к верному выводу по неверной цепочке, и если оператор читает пояснение как обоснование, он наследует эту ошибку. Ваше решение разделить подтверждённые runtime факты и пояснения модели — правильное. Вопрос: как это реализовано в UI — два разных блока, или пояснение модели помечается как «непроверенное»? И не думали ли пойти дальше: генерировать пояснение для оператора из верифицированных фактов runtime, а модель использовать только для нарратива, без числовых утверждений — числа и единицы подставляет runtime? Кажется, это устранило бы целый класс ошибок вроде 82% vs 78,1% и «102,5» без единиц.

Спасибо за содержательный комментарий!

Сейчас в демонстрационном UI подтвержденные наблюдения и решения runtime отделены от свободных пояснений модели, но сами пояснения явно не маркируются как непроверенные и не проходят семантическую валидацию - это ограничение текущего PoC.

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

При этом остается риск, что модель добавит что-то от себя или неверно интерпретирует данные. Поэтому потребуется продумать структуру ответов с учетом конкретных сценариев и отдельно проверить такой подход.

Спасибо за идею, она хорошо дополняет выводы!

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации