Почему правка промптов не решает системные проблемы LLM‑ассистентов

Разработчики, создавшие production‑ассистента для финансовых консультантов, разобрали все сбои, связанные с LLM, и сопоставили их с тем, как их в итоге исправляли. Почти ни одна серьёзная проблема, по их наблюдениям, не решалась простым редактированием промпта. Рабочие решения оказывались архитектурными. Самый сложный сбой команда сначала попыталась починить, меняя текст запроса, но результат стал измеримо хуже, поэтому изменение откатили. После этого модель стали рассматривать как недоверенный компонент внутри более крупной системы.

Самой нестабильной частью оказался механизм routing. Один и тот же вопрос в разных запусках мог уходить по разным путям, хотя код при этом не менялся. На размытых границах между категориями точность маршрутизации держалась примерно на уровне 56–64% и заметно колебалась от запуска к запуску. Например, запрос «rank my households by AUM» иногда приводил к уточняющему вопросу, а иногда система сразу выдавала уверенный ответ. Попытались помочь классификатору, добавив в routing‑промпт более подробные описания категорий, но стало только хуже. Текст в итоге удалили.

Позже выяснилось, что проблема в самой архитектуре. Система сначала пыталась угадать абстрактную категорию запроса, после чего код сопоставлял её с конкретным инструментом. На этом промежуточном шаге часть информации терялась. Если категория определялась неверно, нужный инструмент просто не попадал в доступный набор. Решение оказалось радикальным: абстрактный этап убрали. Теперь маршрутизация сводилась к одному действию, выбору конкретного инструмента из каталога, а область запроса фактически определялась уже выбранным инструментом. Для каждого инструмента добавили несколько примеров пользовательских фраз в виде структурированных данных. После переделки точность сначала просела с нестабильных 98% до 72%, затем выросла до 100% на двух наборах оценочных тестов.

Авторы подчёркивают ещё одну деталь. Некоторые сбои выглядели как ошибки модели, хотя на самом деле система просто не умела выполнять нужное действие. Например, на запрос «show the first account» модель выбирала ближайший доступный инструмент для просмотра holdings и сама придумывала порядковый номер. Причина простая: инструмента для списка аккаунтов в системе не было. Когда его добавили, проблема исчезла.

Был и другой случай. Строка «2pm» попадала в поле, где ожидалась вычисленная временная метка. Парсер не мог обработать такое значение, после чего происходил серверный сбой. Интересно, что баг проявлялся только с реальным выводом модели. В тестах использовали пустые аргументы, поэтому проблему там не видели.