Langfuse помогает видеть цепочку вызовов ИИ-приложения, оценивать ответы и находить причины ухудшения качества. Для агента клиентской поддержки это журнал того, какой запрос пришёл, какие данные были найдены и что ушло клиенту. Польза появляется после выбора метрик и правил доступа к чувствительным данным.
Что показывает трасса
Трасса Langfuse связывает входной запрос, этапы работы приложения и итоговый ответ в одну наблюдаемую последовательность.
Обычный журнал сервера часто сообщает лишь об ошибке вызова. Для ИИ-приложения этого мало: ответ может выглядеть технически успешным, но ссылаться на устаревший документ или пропустить важное ограничение. Трасса позволяет восстановить путь: сообщение пользователя, поиск источников, обращение к модели, ответ и служебные метки. По ней инженер видит место сбоя, а владелец процесса понимает влияние на клиента.
Сначала определите, что является одним запросом в вашей системе. Для поддержки это обращение клиента от вопроса до готового ответа. Для внутреннего помощника — вопрос сотрудника с найденными страницами базы знаний. Если разбить путь на несвязанные записи, выяснить источник ошибки будет трудно. В материале об управлении ИИ-агентами разобраны роли владельцев процесса; Langfuse даёт им наблюдаемые события для решения.
Записывайте только те поля, которые помогают разбору. Сырые сообщения могут содержать персональные данные и коммерческую тайну. Срок хранения, маскирование и доступ задаются до передачи реальных диалогов в систему наблюдения.
Для первого разговора с командой достаточно открыть конкретный ошибочный ответ и пройти его путь шаг за шагом. Такой разбор показывает, какая информация доступна в трассе и каких событий пока недостаёт. Схему наблюдения удобно улучшать на реальном вопросе.
Сигналы качества
| Сигнал | Что означает | Проверка |
|---|---|---|
| Пустой источник | Поиск дал пустой результат | Проверить индекс и запрос |
| Длинная цепочка | Агент делает лишние шаги | Сравнить с нормальной трассой |
| Жалоба клиента | Ответ расходится с ожиданием | Прочитать вопрос и источники |
Качество нельзя свести к одному числу. Оценка полезности ответа, наличие подтверждающего документа, время ожидания и доля передачи человеку показывают разные стороны процесса. Начните с жалоб и ошибочных ответов, которые уже известны команде. Для каждого сохраните трассу и причину: плохой поиск, неверная инструкция, устаревшая база или ошибочная классификация запроса.
При работе с базой знаний важно смотреть на извлечённые фрагменты. Если агент уверенно цитирует старую редакцию инструкции, замена модели вряд ли исправит причину. Сначала обновляют источник и правила поиска. Архитектура такого поиска разобрана в материале о базе знаний RAG.
Команда может вести набор эталонных вопросов для повторной проверки после изменения промпта или источников. Сохраняйте ожидаемый ответ и критерий: какие сведения обязательны, где нужна передача человеку, на какой документ следует опереться.
Отметки качества лучше привязывать к задачам бизнеса. Для консультации клиента важна точность условий; для поиска по регламенту — ссылка на актуальную версию; для черновика письма — необходимость ручной правки. Одна оценка для всех задач скрывает различия.
Подключение наблюдения
- Опишите путь одного запроса: вход, поиск, вызов модели, инструменты, финальный ответ. Назначьте идентификатор, объединяющий шаги.
- Добавьте трассировку в приложение и проверьте на тестовых обращениях, что этапы видны в правильном порядке.
- Настройте маскирование чувствительных полей и роли доступа. Проверьте, что журнал хранит достаточно данных для разбора без раскрытия лишнего.
- Пометьте типовые хорошие и плохие ответы, затем сравните трассы до и после изменения приложения.
Запрос «langfuse trace» обычно означает желание увидеть конкретный путь ошибки. Откройте итоговый ответ, промежуточный поиск, параметры вызова и результат инструмента. Если агент отвечает по пустому контексту, исправлять стиль ответа бессмысленно. Если поиск верен, а вывод неверен, смотрите инструкцию и ограничения модели.
При связке «langfuse litellm» важно заранее договориться, где возникает единый идентификатор запроса и кто отвечает за запись этапов. Иначе вызов модели виден, а связь с клиентским сообщением теряется. Для внутренней архитектуры пригодится разбор ИИ-агентов под рабочий процесс: наблюдение следует за границами ответственности, заданными в самом процессе.
После подключения выберите один конкретный тип ошибки и соберите несколько трасс с одинаковым симптомом. Повторение покажет, где менять систему.
Проверьте трассу из двух точек: из карточки обращения и из интерфейса наблюдения. Путь должен вести к одной записи. Иначе сотрудник поддержки описывает ошибку своими словами, а инженер тратит время на поиск похожего события в журнале.
Поиск деградации
Деградация редко выглядит как полный отказ. Агент постепенно чаще просит уточнение, дольше ищет источник или даёт общие ответы там, где раньше называл конкретный пункт инструкции. Сравнивайте новые трассы с эталонными вопросами и периодами, когда команда была довольна качеством. Одновременно отмечайте изменения базы знаний, системной инструкции и инструментов: без этой истории корреляцию легко принять за причину.
Разбор спорного ответа начинается с вопроса клиента. Затем инженер смотрит найденные документы и последовательность вызовов; предметный эксперт подтверждает, какие факты были верны. Только после этого команда меняет промпт, индекс или правило передачи человеку. Если исправление принято наугад, похожая ошибка может вернуться в другой форме.
- Техническая ошибка: вызов завершился с исключением или пустым результатом.
- Содержательная ошибка: все шаги выполнились, а ответ оказался неверным.
- Процессная ошибка: агент ответил там, где требовалось согласование сотрудника.
У этих случаев разные владельцы и способы исправления. Отчёт по качеству полезен, если он связывает симптом с действием команды и показывает конкретную трассу ошибки. Для руководителя достаточно тенденции по критичным ошибкам и примеров с решением; инженеру нужна полная трасса.
Особое внимание уделяйте случаям с удачным техническим ответом и плохим содержанием. Такой запрос редко попадёт в обычный список ошибок. Ручная выборка ответов с пометками эксперта помогает выявлять проблему до того, как её повторят другие клиенты.
Какие ответы агента сейчас вызывают жалобы?
Свой контур данных
Langfuse можно развернуть в собственном контуре, если организация хочет хранить трассы под своим управлением. При этом размещение само по себе оставляет вопросы безопасности: нужны права доступа, правила удаления и контроль того, какие поля отправляет приложение. Особенно важно исключить пароли, ключи и лишние данные клиентов из журналов.
Начните с тестовых диалогов и заранее определите срок хранения трасс. Затем подключайте рабочие обращения поэтапно, проверяя маскирование на реальных форматах сообщений. Для автоматизации проверки удобно сочетать трассы с выборкой ручных оценок экспертов. Полный просмотр каждого ответа быстро превращается в отдельную нагрузку на команду.
Выберите один повторяющийся сбой агента и восстановите его путь по этапам. Если нужного шага в трассе нет, сначала добавьте событие; метрики качества появятся после наблюдаемости.
Стоимость внедрения зависит от объёма событий, архитектуры приложения и требований к данным. В смете полезно отдельно видеть подключение трасс, хранение, оценку ответов и работу экспертов. Так бюджет опирается на состав работы и требования к данным.
Развёртывание у себя добавляет работу по обновлениям, резервным копиям и доступу команды. Назначьте владельца этих задач до запуска. Тогда журнал наблюдения останется доступен именно в момент разбора сбоя, когда у поддержки уже есть конкретное обращение.