Ошибка не в LLM: как архитектура маскирует проблемы под качество модели

Опыт внедрения LLM в клиентских сервисах выявил опасный паттерн: когда LLM даёт неправильный ответ, часто это не её вина.

Демо vs реальность

На пилотном демо система работала идеально: модель отвечала живо, бизнес видел прогресс, команда сравнивала разные LLM и крутила промпты. Потом пришли реальные пользователи, реальные данные и реальные ограничения. Ответы стали уверенные, но иногда неверные.

Вина не в модели

Команда планировала замену на более мощную LLM. Но разбор логов показал: в части диалогов модель вообще не должна была отвечать. Routing отправлял пользователя в ветку answer, хотя API возвращал partial response — в таких случаях нужен handoff к человеку.

• Проблема была в маршрутизации, не в качестве генерации
• API возвращает partial — система должна отправить в поддержку
• Но LLM получала partial как полный ответ и писала убедительную, но неверную генерацию
• Модель красиво озвучивала ошибки архитектуры

Где жили настоящие ошибки

Самые дорогие баги не были в LLM. Они были в:

• Routing — неверно отправляет пользователей по веткам
• API-интеграции — partial vs full response не различаются
• Handoff-логике — когда переходить человеку
• Базе знаний — outdated или incomplete информация
• Compliance-слое — соответствие регуляциям
• Метриках — что вообще считается ошибкой

Перелом

Перенос произошёл, когда вопрос изменился. Вместо «Почему LLM ответила неправильно?» команда спросила: «Почему система поставила модель в ситуацию, где правильного ответа быть не могло?»

Вывод горький: сильная LLM не компенсирует слабую архитектуру. Если нет нормального routing, владельца knowledge base и ясной handoff-логики, сравнение моделей часто становится дорогим отвлекающим манёвром. Лучше потратить время на систему, чем на промпты.