Зачем бизнесу видеть путь одного ответа

Когда ИИ-агент отвечает клиенту 40 секунд, слово «модель тормозит» почти ничего не объясняет. За это время система могла искать документы, несколько раз обращаться к модели, повторять неудачный вызов инструмента, ждать CRM или проверять разрешение на действие. Если все этапы записаны одной строкой «запрос начался — ответ готов», руководитель видит жалобу и счёт за токены, но не причину.

Руководство Langfuse по качественной трассировке предлагает считать одной трассой законченную единицу работы — например, один ответ чат-бота или один запуск агента. Внутри него должны быть различимы вызовы модели и инструментов. На официальном снимке интерфейса видно дерево шагов с разной длительностью. Это демонстрация инструмента, не замер типичного российского бизнеса. Полезная схема — измерять путь конкретной заявки через модель, поиск и интеграции, а не только среднее время ответа LLM.

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

Что записывать в трассу

Трасса — история одного пользовательского запроса. Она состоит из вложенных отрезков работы, или spans: приём заявки, проверка доступа, поиск, вызов модели, вызов инструмента, валидация результата и подтверждение человеком. Общий `trace_id` позволяет сопоставить их без склейки журналов по времени и имени клиента.

Практический минимальный набор полей для каждого шага:

  • название операции и её длительность;
  • код результата и тип ошибки без содержимого запроса;
  • версия сценария, модели и инструмента;
  • количество входных и выходных токенов там, где оно доступно;
  • число повторных попыток и признак передачи человеку;
  • обезличенный идентификатор процесса или заказа, пригодный для внутренней сверки.

Langfuse рекомендует показывать каждый вызов модели отдельным шагом `generation`, а вызов инструмента — как `tool`, рядом с породившей его генерацией. Тогда не теряются повторные обращения и расход контекста внутри цикла агента. Названия шагов стоит делать стабильными и описывать действие, например `retrieve-context`: динамический номер заказа в имени сломает группировку. Для бизнес-показателя добавьте собственный результат: ответ принят без правок, исправлен сотрудником, отклонён или завершился ручной обработкой. Без этого «быстро» легко перепутать с «полезно».

На практике цепочка для помощника отдела продаж может выглядеть так: заявка поступила из формы; агент извлёк действующий прайс и условия доставки; модель подготовила предложение; детерминированный код сверил цену и обязательные поля; менеджер подтвердил отправку. Если поиск прайса занял 12 секунд, а модель — 3, замена модели не устранит основную задержку. Если трижды повторился запрос к CRM, причина может быть в таймауте, а не в «неумном» ИИ.

Архитектура без отдельной платформы ради графика

Для пилота достаточно инструментировать один сервис, который запускает бизнес-процесс, и передавать трассы по OTLP в уже имеющееся средство наблюдения. Если такого средства нет, локальный просмотрщик годится для короткого испытания, но не становится автоматически промышленным хранилищем. Документация OpenTelemetry показывает Collector как промежуточный узел: он принимает телеметрию, обрабатывает и отправляет её в выбранный backend. Права, срок хранения и сетевое размещение остаются решением компании.

Корневой span создавайте на входе заявки. Передавайте контекст дальше через поиск, локальный сервер модели и адаптеры CRM, чтобы дочерние операции принадлежали той же трассе. Для действия с последствиями — отправки письма, изменения цены, записи в ERP — фиксируйте отдельный шаг и итог одобрения, но сам инструмент должен оставаться за шлюзом с проверкой полномочий. Наблюдаемость не заменяет защиту: трасса покажет несанкционированную попытку, но не обязана уметь её остановить.

Локальная модель уместна, когда данные, политика или нагрузка оправдывают собственный контур. Трассы при этом могут оставаться внутри той же сети. Если у компании один редкий вызов модели без инструментов, полноценная распределённая трассировка может быть избыточной: начните с времени ответа, числа ошибок и стоимости принятого результата. RAG нужен, если ответ опирается на изменяющиеся документы; трассировка нужна, чтобы увидеть задержку и качество каждого этапа RAG. Это разные задачи, и одна технология не подменяет другую.

Не превратить мониторинг во вторую копию конфиденциальных данных

Главный риск — включить запись полного текста запроса «для отладки». Руководство Langfuse рекомендует осмысленные входы и выходы шагов для последующего анализа, но это не обязывает записывать производственные секреты в каждую трассу. OWASP относит персональные, финансовые, медицинские и коммерческие сведения к чувствительной информации. Если такая информация попадёт в трассы, компания получит ещё одно хранилище с доступами, сроками удаления и риском утечки. Для чувствительных процессов проектируйте маскирование до экспорта и проверяйте результат тестовым маркером.

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

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

Как считать пользу, а не количество красивых графиков

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

Пример модельного расчёта: 2 000 обращений в месяц, у 10% из них один лишний повторный вызов стоимостью условные 3 рубля. Устранение повторов высвободит 600 рублей прямых переменных затрат. Если оно одновременно сократит работу сотрудника по 2 минуты в 200 случаях, это ещё 6,7 часа; при условной полной стоимости часа 1 200 рублей — около 8 000 рублей ресурса. Сумма зависит от реальной загрузки: освободившееся время не равно денежному притоку, если его не используют. Эти числа не взяты из демонстрации Langfuse.

Хранение 100% подробных трасс тоже имеет цену. Для малой нагрузки допустим полный короткий пилот, а после него — срок хранения, лимит объёма и выборка. OpenTelemetry различает выборку в начале запроса и после завершения трассы; второй способ позволяет сохранить медленные или ошибочные случаи, но требует больше памяти и управления. Не добавляйте сложный tail sampling до появления измеренной проблемы объёма. Если ошибка редкая и критичная, позаботьтесь, чтобы выбранная политика её не выбросила.

Пилот на десять рабочих дней

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

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

Смысл трассировки для бизнеса простой: она превращает спор «какая модель медленная» в проверяемый вопрос «какой шаг мешает закрыть заявку». Решение о расширении пилота принимайте по принятому результату и стоимости процесса. Обложка — квадратный кроп официального снимка Langfuse из репозитория документации под лицензией MIT; интерфейс показан как пример, не как обязательный продукт для внедрения.