Палец вниз — это сигнал, а не диагноз

Сотрудник спросил корпоративный RAG-ассистент о сроке возврата товара и нажал «ответ неверный». Можно немедленно переписать промпт. Можно добавить еще документов. Можно обвинить модель — Внутрик уже заботливо открыл для этого отдельную папку. Но ни один из этих шагов не следует из одного нажатия. Причина может быть в устаревшем регламенте, плохом поиске, неверном пересказе найденного пункта или в том, что сотруднику нужен ответ по другому филиалу.

Для малого бизнеса ценность кнопки обратной связи появляется только тогда, когда жалоба превращается в воспроизводимый случай, конкретное исправление и повторную проверку. Документация Langfuse показывает техническую часть этой цепочки: оценку пользователя можно связать с трассой ответа, отправить ее на ручную разметку и затем сохранить случай в тестовом наборе. Это пример доступного инструментария, а не требование ставить именно Langfuse. NIST в AI Risk Management Framework отдельно относит процессы сообщения о проблемах к измерению и оценке системы.

Какой контекст сохранить при жалобе

Если оставить только «👎» и текст ответа, через неделю уже трудно понять, что видел ассистент. Нужна минимальная карточка инцидента:

  • Идентификатор запроса, время, бизнес-процесс и обезличенная роль пользователя.
  • Исходный вопрос и ответ — только в объеме, который разрешено сохранять; при необходимости вместо полного текста сохраняются защищенная ссылка и маскированная версия.
  • Идентификаторы найденных документов, версии или даты их действия, фрагменты-основания и результат проверки прав доступа.
  • Версии поискового индекса, модели и промпта, настройки поиска и код ошибки инструмента, если он был.
  • Оценка пользователя, его короткий комментарий и статус разбора: новая, подтверждена, исправлена, не воспроизводится.

Это редакционный минимальный набор полей для проекта, не перечень обязательных полей продукта Langfuse. Сохранять полные клиентские договоры в журнале «на всякий случай» не нужно. Документация Langfuse по маскированию напоминает важный технический принцип: чувствительные данные лучше скрывать еще на стороне приложения, до передачи в систему наблюдения. Для локального контура отдельно проверьте, кто видит трассы, как долго они хранятся и можно ли восстановить исходный документ по ссылке.

Пять разных причин одного «неверно»

Разбор удобно вести не по эмоциональности комментария, а по месту разрыва цепочки.

1. **В базе нет правильного правила.** Владелец процесса обновляет источник, дату действия и ответственного за публикацию. Замена модели не создаст отсутствующий документ.
2. **Правило есть, но поиск его не поднял.** Проверяют разбиение документа, фильтры филиала, ключевые слова, гибридный поиск и ранжирование на том же запросе.
3. **Нужный фрагмент найден, но ответ исказил его.** Меняют формат ответа, цитирование, ограничение на вывод или модель и тестируют на этом фрагменте. Одной красивой ссылки недостаточно, если вывод неверен.
4. **Ответ из чужой роли или версии.** Это не «мелкая галлюцинация», а проблема прав или актуальности. До исправления такой класс ответов лучше блокировать либо эскалировать человеку.
5. **Вопрос неоднозначен или ожидание неверно.** Иногда пользователь имел в виду иной продукт, регион или дату. Тогда ассистент должен спросить уточнение, а не уверенно выбрать случайный вариант.

При смешанной ошибке фиксируйте первичную причину и вторичные факторы. Если в одном случае исправить одновременно индекс, промпт и модель, будет сложно понять, какое изменение сработало. Юмор Внутрика здесь заканчивается: чужая цена, срок или право доступа могут обойтись бизнесу дорого.

От жалобы к проверяемому изменению

Для каждого подтвержденного случая эксперт задает ожидаемое поведение: правильный ответ с конкретной версией источника либо корректный отказ и вопрос на уточнение. В Langfuse ручные очереди разметки позволяют назначать экспертам трассы и записывать оценку или исправленный вывод; наборы данных позволяют перенести производственный пример в повторяемый тест. Эти функции не обучают модель автоматически и сами не доказывают, что исправление безопасно.

Проверка должна включать не только «сломанный» вопрос. Добавьте соседние запросы: другой филиал, старую версию правила, похожий товар, пользователя без доступа. Затем прогоните старую и новую конфигурации на одном наборе. Смотрите долю корректных ответов, ложных уверенных ответов, корректных отказов, задержку и стоимость. Если улучшение одного случая ухудшило десять соседних, публикацию изменения стоит остановить.

Роли полезно разделить: владелец регламента подтверждает смысл; эксперт по предметной области размечает пример; инженер меняет поиск или промпт; ответственный за запуск принимает решение о выпуске. В маленькой компании один человек может исполнять несколько ролей, но отметка о том, кто принял решение, всё равно нужна. Для ответов с высоким риском, например по платежам или кадровым условиям, маршрут к человеку должен оставаться доступным даже после исправления.

Экономика очереди обратной связи

Не каждый «👎» стоит одинакового часа. Сначала берите повторяющиеся и дорогостоящие ошибки: неверный срок обслуживания, условия договора, реквизиты, ограничение доступа. Редкий вопрос о мелочи можно отложить. Полезная метрика — не число собранных оценок, а доля подтвержденных проблем, закрытых проверенным изменением без повторного появления на контрольном наборе.

Пример модельного расчета: за две недели ассистент получил 1 000 вопросов и 60 отрицательных оценок. Эксперт проверил 40, подтвердил 24, из них 10 относятся к одному устаревшему регламенту. Обновление источника и тестов может устранить больше повторных ошибок, чем дорогое дообучение модели. Числа здесь вымышлены для иллюстрации приоритизации, а не результаты компании. Затраты на разметку, интеграции и поддержку нужно сопоставлять с предотвращенными ошибками и временем сотрудников.

Кнопка с оценкой тоже имеет смещение: чаще жалуются раздраженные пользователи, а молчание не означает правильный ответ. Поэтому добавьте случайную выборку обычных ответов и экспертный контроль важного процесса. Сигналы пользователя помогают найти проблемы, но не заменяют независимую проверку качества.

С чего начать без платформенного проекта

На двухнедельном пилоте выберите один процесс и одного владельца знаний. Сохраняйте идентификатор ответа, версии источников и безопасный минимум контекста. Разбирайте негативные оценки раз в несколько дней, назначайте категорию причины и ожидаемое поведение. Из каждого подтвержденного дефекта делайте тест, затем сравнивайте конфигурации на одинаковом наборе до выпуска. Можно начать с таблицы и простого журнала; отдельная платформа оценки имеет смысл, когда объем и число участников делают ручной учет ненадежным.

Успех выглядит скромнее лозунга «ассистент самообучается»: команда знает, почему ответ был неверным, исправляет именно этот слой и может доказать, что соседние ответы не сломались. Внутрик вправе собирать пальцы вниз пачками; решение о ремонте базы знаний все равно остается за людьми.