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

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