Эпилог спасательного проекта и ответы на некоторые вопросы

(В прошлых сериях: 1, 2, 3, 4, 5, 6+7)

Клиент потом довольно сказал, что “was very happy about the current figures”. И это при том, что команда честно поделилась оценками качества на тестовом наборе данных, где собраны самые неприятные моменты.

В команде подключают новые источники данных. Прикидывали заранее, что на них качество упадет до 70% из-за овертюна и отличающейся доменной модели - некоторые термины и методики в новых документах отличаются принципиально. Особенно в тех SGR каскадах, где клиент и eval team до сих пор не пришли к единому пониманию, как это правильно считать.

По факту же общее качество… поднялось до 85.9%. Это все из-за правки системных ошибок, которые стали очевидными после добавления третьего источника данных. В итоге получается 85.3% и 83.9% на известных источниках и 78.3% на новом (это правый столбец шириной ~20 квадратов на скришоте, он очень заметен). И вот тот самый раздражающий блок красных ошибок - это и есть поля, в которых в SGR схеме не прописана нормально методология извлечения.

Заодно, в комментариях выложил скриншот того самого Excel с ground truth (для оценки масштабов работы eval команды, содержимое ячеек там не разобрать)

Про успех проекта директора рассказали по всей компании, отдельно выделив работу eval команды. Ну и заодно показали цифры про количество кода, “который никто не видел”. Это нужно, чтобы команды исподволь привыкали к двум вещам:

(1) тесты и инженерный подход - это наше все, особенно в проектах c LLM под капотом.
(2) код - это просто формат для компактного хранения данных и поведений. Он, как и веса моделей, не так важен при наличии тестов и процесса “обучения”

Правильный менталитет и привычки, дадут командам этой компании фору на рынке. Ну а то, что конкуренты ругаются на попрание норм разработки и неправильность подходов - пусть себе ругаются. Клиентов интересуют в первую очередь результаты.

Внутри же чаще всего спрашивают про устройство пайплайна и раутинг запросов к агентам. Про это я писал ранее, но еще раз повторюсь - два основных промпта, как и в простейшем RAG. Один - Retrieval, второй - Generation. Качество результатов всегда упирается в первый шаг.

Первый промпт делает тщательный анализ документа, используя ветвистый SGR с кучей оптимизированных каскадов.

Второй промпт генерирует код инструмента для извлечения, который будет вызван следующим шагом. Если сгенерированный код не проходит проверки, то в контекст докидывается информация, ползунок reasoning для gpt-5-mini выкручивается в high, и агент отправляется работать над ошибками.

Сложного и гибкого раутинга тут нет - есть жесткие рельсы, которые отбирают свободу, но позволяют оценивать качество и улучшать его.

Да и не нужна чрезмерная свобода агентам в типичных бизнес-задачах. Можно построить гибкую систему на фиксированных шагах с измеримым качеством.

А тем временем директор этой компании прислал здоровущий Excel от биотеха с тремя вопросами:

(1) это вообще делается?
(2) сколько времени надо?
(3) какое будет качество?

Ответ? "Есть идеи. Пять дней и eval команду, тогда скажем точнее"

Ваш, @llm_under_hood 🤗