Глава 6 — Наблюдаемость и трассировка ИИ

Шестой пост поглавного разбора LLM Primer V: Building Real-World LLM Applications. Глава, относящаяся к пользовательскому запросу как к причинному дереву, а не как к записи лога, и показывающая, что надо трассировать, чтобы это дерево было читаемым.

Почему существует эта глава

Один пользовательский запрос в LLM-системе разворачивается в дерево: переписывание запроса, три вызова retrieval против двух индексов, rerank, вызов планировщика, четыре вызова инструментов, суммаризатор и финальная генерация. Схлопните это дерево в «запрос принят, ответ отправлен» — и правда исчезнет. Когда пользователь жалуется, что ответ был неверным, команда не может сказать, промахнулся ли retrieval мимо нужного чанка, выбрал ли планировщик не тот инструмент, вернул ли инструмент не те данные или генератор проигнорировал то, что ему дали. Глава 6 перестраивает наблюдаемость под эту форму. Классическая распределённая трассировка — субстрат; семантические соглашения OpenTelemetry GenAI — расширение, делающее модельные вызовы гражданами первого класса; LLM-специфичные метрики — TTFT, TPOT, стоимость на вызов, оценки судьи — то, что превращает трейс в нечто, против чего команда может оперировать.

Если коротко: наблюдаемость LLM — это распределённая трассировка плюс семантические соглашения GenAI плюс небольшой набор метрик (TTFT, TPOT, стоимость, качество) и экспортный конвейер, превращающий продакшен-трейсы в eval-набор для следующего релиза.

6.1 От логов запросов к причинным трейсам

Переход — от плоских логов запросов к вложенным спанам. OpenTelemetry с семантическими соглашениями GenAI даёт переносимые, provider-нейтральные формы спанов для LLM-вызовов, эмбеддингов, retrieval и вызовов инструментов. Цикл агента становится корневым спаном; каждая итерация — дочерним спаном; каждый LLM-вызов, вызов инструмента и retrieval гнездятся под ними. Многоходовые сессии становятся деревьями из деревьев, а span-link-и моделируют состояние, разделяемое между ходами: резюме из третьего хода, на которое седьмой ход всё ещё опирается. Ценность проявляется при первой же отладке: «какой чанк retriever поднял на этот запрос и действительно ли генератор его процитировал» — вопрос, на который плоские логи не отвечают без археологии, — становится одним трейсом, на который надо посмотреть. Форма спана переносима между вендорами, потому что это стандарт OpenTelemetry, а не проприетарный формат, и переход с LangSmith на Langfuse становится изменением маршрутизации, а не переписыванием.

6.2 Метрики, которые важны — TTFT, TPOT, стоимость, качество

Полной задержки недостаточно. Time-to-first-token доминирует над воспринимаемой скоростью для стриминга — пользователь смотрит на первый символ, а не на последний, — и TTFT принадлежит спану наряду с полной задержкой. Time-per-output-token доминирует над ощущением длинных ответов и есть то, что пользователь чувствует, говоря «медленно доканчивал». Стоимость принадлежит спану как атрибут первого класса, вычисленный на месте вызова по версионированной таблице цен, так что исторический трейс говорит правду и после того, как цены поменялись. Сигналы качества — палец вниз от пользователя, оценка судьи из оценочного конвейера, срабатывание фолбэка внутри обёртки — цепляются к трейсу как атрибуты, и это то, как команда сопоставляет плохой ответ с конкретным модельным вызовом и retrieval, которые его произвели. Метрики видны на дашбордах, но большая отдача — в том, что их можно запрашивать по трейсу: регрессию можно отфильтровать по «высокая стоимость, низкая оценка судьи», и путь-виновник всплывёт сразу.

6.3 Платформы и замыкание петли

Четыре платформы занимают текущий ландшафт. LangSmith — LangChain-интегрированный выбор с минимальным трением, если приложение уже на LangChain. Langfuse — open-source-self-hosted-вариант, подходящий для регулируемых развёртываний и организаций, которым трейсы должны оставаться внутри периметра. Arize Phoenix силён embedding-анализом и правильный инструмент, когда диагностический вопрос — «какие запросы приземляются не в ту область векторного пространства». Helicone работает как прокси перед провайдерским API — это интеграция с наименьшим касанием, но она видит только слой LLM-вызова. Выбор — операционный, а не качественный: большинство из них выставляют одну и ту же базовую форму. Более ценная работа — экспортный конвейер: трейсы с негативным фидбэком, низкими оценками судьи и срабатываниями фолбэка становятся кандидатами в eval, курируются в eval-набор и гейтируют следующий релиз. Именно эта петля превращает продакшен в учителя для разработки.

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

Что подготавливает глава 6

Трейсы — это ещё и то, где становятся видны инциденты безопасности. Успешная prompt-инъекция выглядит в дереве трейса как неожиданный вызов инструмента. Эксфильтрация выглядит как retrieval-спан, чей чанк модель затем послушалась как инструкцию. Утечка системного промпта проявляется как completion-спан, чей текст неправдоподобно перекликается с промптом выше. Глава 7 обращает тот же трассировочный субстрат в сторону дисциплины безопасности: OWASP LLM Top 10 как словарь середины 2025-го, таксономия «прямая vs косвенная инъекция», которую этот словарь пытается назвать, и четырёхслойная матрица митигаций, обеспечивающая принцип «полномочия должны соответствовать происхождению доверия».

Дальше — Глава 7: Безопасность LLM и guardrails. Постура безопасности, отвечающая на вопрос, который слой трассировки только что сделал задаваемым: что должно было произойти и кому было позволено это сделать.

Хочется всю картину? Книжная глава детально проходит атрибуты span-ов OpenTelemetry GenAI, SDK-интеграции Langfuse и LangSmith с конкретным кодом, таблицу атрибуции стоимости с версионированием и экспортный конвейер трейсов в evals. LLM Primer V на Amazon →