Слепота разработчика: когда логи зеленые, а пользователи уходят
Каждый инженер, который выкатывает в продакшен продукт на базе LLM, рано или поздно проходит через стадию отрезвления. На этапе разработки всё выглядит превосходно. Ты тщательно полируешь системный промпт, подкручиваешь параметры температуры, собираешь сложный RAG-пайплайн и прогоняешь набор подготовленных тестовых запросов. Нейросеть выдает блестящие, структурированные ответы. Дашборды показывают нормальные тайминги, автотесты светятся зеленым, и фича уезжает в релиз.
А потом приходят настоящие пользователи. В отличие от QA-инженеров, они не пишут идеальные академические промпты. Они вбрасывают обрывки фраз, прикрепляют огромные неформатированные куски кода с ошибками, задают вопросы с диким количеством опечаток. Модель, столкнувшись с таким мусором на входе, начинает генерировать очень уверенные, но абсолютно бредовые ответы — то есть галлюцинировать. Пользователь читает этот сгенерированный бред, разочаровывается и молча закрывает вкладку.
Что в этот момент видит бэкенд-разработчик? В системе мониторинга график HTTP-статусов горит зеленым светом. Сервер вернул HTTP 200 OK. Время ответа — приемлемые 1200 миллисекунд. Интеграция с OpenAI или локальной моделью работает как часы. Возникает классическая "слепота разработчика": технически сбоев нет, ошибки в Sentry не падают, но продуктовая ценность взаимодействия стремится к нулю. Без явной обратной связи от пользователя мы летим вслепую. Единственный способ прозреть — заставить самого пользователя явно размечать качество ответов.
Кнопки 👍 / 👎: Больше, чем просто элемент интерфейса
Самый дешевый в реализации и понятный любому пользователю механизм сбора фидбека — классические кнопки Thumbs up и Thumbs down под сообщением бота. Но поставить две иконки на фронтенде — это даже не десятая часть инженерной задачи.
Изолированные UI-кнопки абсолютно бесполезны, если клик по ним нельзя жестко и однозначно связать с полным техническим контекстом генерации. Представьте: в базу падает запись user_123 поставил дизлайк. Что с этим делать? Для расследования инцидента инженеру нужно знать десятки параметров. Какой именно системный промпт ушел в модель в тот момент? Каким был контекст предыдущих сообщений? Какая конкретно модель сгенерировала этот ответ? Какие чанки текста из векторной базы подмешались в запрос? Без этих сырых данных дизлайк превращается в абстрактную жалобу, которую невозможно пофиксить.
Нам нужна сквозная трассировка (end-to-end tracing) от клика мышки в браузере до глубоких логов AI-шлюза.