"Эпилог спасательного проекта и ответы на некоторые вопросы __(В прошлых сериях: ____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 🤗"