Какие инструменты наблюдаемости LLM видят главное?

Продукт для наблюдаемости не скажет, исправно ли работает функция на базе LLM, пока вы сами не определите, что значит «исправно». Большинство инструментов умеют рисовать привлекательные трассировки и суммировать токены. Гораздо меньше продуктов способны связать плохой ответ с вызвавшим его этапом поиска, отнести лишние расходы к конкретному клиенту и функции, а затем предупредить об изменении успешности задач до того, как начнут поступать обращения в поддержку.

Этот пробел существенен, потому что сбои LLM редко похожи на обычные программные ошибки. Запрос возвращает код 200. Задержка остается в пределах целевого значения. Модель выдает складный текст. При этом агент выбирает не тот инструмент, модуль поиска передает ему устаревшие правила или цикл повторных попыток тратит шесть долларов на задачу ценностью в пятьдесят центов. Рядом со сломанным продуктом вполне может гореть зеленым панель состояния инфраструктуры.

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

Трассировка фиксирует выполнение, но не правильность

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

Эти понятия смешивают, потому что интерфейсы трассировки LLM показывают промпты и ответы, то есть выглядят содержательнее обычных спанов. Более подробные свидетельства все равно остаются свидетельствами, а не суждением. По трассировке видно, что агент вызвал search_orders, получил три записи и составил вежливый ответ. Она не знает, что пользователь спрашивал о возврате средств, что агенту следовало вызвать refund_status и что ответ противоречит правилам компании.

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

Видимости на шлюзе достаточно, когда функция состоит из одного промпта и одного ответа. Она начинает вводить в заблуждение, когда агент повторяет попытки, вызывает платные инструменты, ищет документы или передает работу дальше. Вызов модели стоимостью $0.10 может входить в процесс стоимостью $2. Хуже того, неудачная первая попытка исчезнет из итогового ответа, но останется в счете.

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

Не спрашивайте, умеет ли продукт строить трассировки. Спросите, где начинается его корневой спан, какие дочерние операции он создает автоматически, как контекст проходит через очереди и сервисы, какие данные он отбрасывает или скрывает. Дорогая загадка обычно находится именно в пропущенном спане.

Глубина трассировки определяет объяснимый сбой

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

LangSmith описывает операцию как трассировку из запусков, а трассировки объединяет в проекты и цепочки диалогов. Его интеграции особенно естественны для LangChain и LangGraph, а обертки и ручное инструментирование охватывают остальной код. Он удобен, когда инженеру нужно изучить путь агента, сравнить запуски, приложить обратную связь и перенести производственный пример в набор для оценки. Прием данных OpenTelemetry уменьшает зависимость от одного фреймворка, но самая подробная автоматическая структура по-прежнему зависит от используемых интеграций.

Langfuse записывает трассировки, спаны, генерации, события, сессии, оценки, расход модели и версии промптов. В документации сказано, что каждое наблюдение может содержать время, вход, выход и сведения о стоимости. Такая модель данных подходит командам, которым нужно одно место для производственных трассировок, управления промптами, оценок и экспериментов. Развертывание открытой версии и современные SDK на базе OpenTelemetry дают больше контроля над хранением и экспортом. Однако контекст через собственные фоновые задания придется передавать самостоятельно, как и размечать бизнес-параметры.

Phoenix принимает трассировки OpenTelemetry и использует соглашения OpenInference для вызовов моделей, поиска, инструментов и других операций ИИ. Поэтому Phoenix разумно выбирать, если вам нужен открытый слой инструментирования и анализ локально или на собственной инфраструктуре. Он особенно полезен для изучения поиска и прикрепления оценок к спанам. Phoenix показывает лишь те операции, которые отправили инструменты автоматического сбора или ваши ручные спаны, поэтому аккуратное дерево трассировки еще не доказывает, что в него попало каждое решение.

Helicone может находиться на пути запросов к поставщику как шлюз или получать данные через SDK. Такое положение быстро дает видимость запросов к модели, расходов, задержки, ошибок, сессий и пользовательских свойств без необходимости оборачивать каждую функцию приложения. Это хороший вариант, если первая задача связана с трафиком поставщика и расходами. Шлюз не выведет из данных внутреннее решение маршрутизатора, незаписанный результат инструмента или бизнес-исход процесса. Если эти вопросы важны, добавьте спаны приложения.

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

Эта карта границ нужна лишь как отправная точка, а не как вечный вердикт о функциях. LangSmith особенно силен в запусках агентов и оценке. Langfuse ведет открытый инженерный журнал LLM, связывая генерации, версии промптов, оценки и параметры расходов. Phoenix делает упор на открытые телеметрические данные, анализ поиска и эксперименты. Helicone контролирует границу поставщика. Datadog связывает вызов ИИ со всей производственной системой. Возможности продуктов меняются, как и ваша архитектура. До подписания долгого контракта проверьте весь путь на собственной трассировке.

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

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

Распределение расходов начинается с ваших параметров

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

Большинство специализированных инструментов рассчитывают стоимость модели по данным об использовании от поставщика и таблице цен. LangSmith автоматически записывает токены и расходы для основных поставщиков, а также принимает собственные данные о расходах для моделей и других запусков. Langfuse может принять расход и стоимость напрямую либо вычислить их по описанию модели. Его документация справедливо отдает предпочтение данным поставщика, когда они доступны. Phoenix отслеживает токены, задержку и цену модели при наличии обязательных атрибутов и тарифов. Helicone рассчитывает стоимость на шлюзе и разбивает трафик по пользовательским свойствам. Datadog тоже считает расходы поддерживаемых поставщиков и помечает трассировки как частично рассчитанные, если для некоторых спанов LLM нет цены.

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

Для распределения нужны стабильные параметры в момент приема данных. Я использую tenant.id, feature.name, environment, release, prompt.version, model, workflow.name и конечный outcome. Для агента из многих шагов я также записываю число попыток и факт вмешательства человека. Идентификаторы пользователей стоит псевдонимизировать, если операторам не нужно знать личность. Для промптов и найденных документов нужны явные правила удаления чувствительных данных, а не расплывчатая надежда на осторожность инженеров.

Ниже показан минимальный полезный контракт для завершенного процесса. Названия полей можно изменить, но связи между ними должны сохраниться:

{
  "trace_id": "01J...",
  "tenant.id": "tenant_42",
  "feature.name": "invoice_reconciliation",
  "workflow.name": "match_and_explain",
  "release": "2026.08.3",
  "prompt.version": "invoice-v17",
  "model": "provider/model-version",
  "attempt.count": 2,
  "usage.input_tokens": 18420,
  "usage.output_tokens": 912,
  "cost.model_usd": 0.184,
  "cost.tools_usd": 0.031,
  "outcome": "human_corrected",
  "quality.task_success": 0
}

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

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

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

Для дрейфа качества нужен оцененный производственный сигнал

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

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

LangSmith может запускать оперативные оценщики для производственных трассировок, хранить обратную связь, строить графики качественных показателей и отправлять предупреждения через вебхуки или PagerDuty. Langfuse хранит числовые, категориальные, логические и текстовые оценки от пользователей, программ, людей или моделей-судей. Его мониторы предупреждают по порогам наблюдений или агрегированных оценок, включая долю успешно пройденных логических проверок. Phoenix поддерживает программные, человеческие и модельные оценки, прикрепленные к трассировкам и спанам. Сам Phoenix особенно хорош как рабочая среда для доказательств и оценки, а глубина управляемого мониторинга различается между Phoenix и более широкой платформой Arize. Helicone предупреждает об операционных показателях, включая частоту ошибок, стоимость, задержку, токены и число запросов. Если там нужен семантический дрейф качества, передавайте оценку в отдельный монитор или проверьте актуальный путь предупреждений для вашей редакции. Datadog объединяет оценки и мониторы в общей операционной системе, что полезно, когда качество и состояние сервиса должны оповещать одну команду.

Модели-судьи полезны, но это не истина. Они могут измениться после смены судейской модели, поощрять многословие, пропускать отраслевые правила и добавлять расходы к каждой выбранной трассировке. Зафиксируйте версию модели и промпта судьи. Храните проверочный набор, размеченный людьми. Следите за расхождением с человеческими оценками. Для фактов, которые способна решить программа, используйте детерминированные проверки: корректность JSON, запрещенные поля, наличие цитат, выбор инструмента и арифметику.

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

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

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

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

Любая платформа пропустит незаписанный контекст

Самые большие слепые зоны появляются из-за решений об инструментировании и управлении данными, а не из-за отсутствующей функции панели. Команды регулярно обвиняют продукт, отправив в него неполные, выборочные или небезопасные данные.

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

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

Асинхронный контекст тоже часто теряется. Запрос API ставит задание в очередь, обработчик начинает новую корневую трассировку, и финальный вызов модели выглядит не связанным с действием пользователя. Стоимость делится между двумя трассировками, а график задержки не включает ожидание в очереди. Передайте через сообщение контекст W3C или явный корреляционный идентификатор. Убедитесь в интерфейсе, что цепочка сохранилась, а не полагайтесь на флаг конфигурации SDK.

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

Наконец, ни один из этих продуктов автоматически не знает экономику задачи. Он может показать, что процесс стоил $1.40 и получил оценку 0.82. Только ваше приложение знает, обработал ли он счет на $20, сэкономил ли час работы поддержки или создал проблему, которую пришлось исправлять человеку. Записывайте исход рядом с бизнес-транзакцией, затем связывайте его с трассировкой.

Самый дешевый инструмент может породить дорогую телеметрию

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

Один обмен в чате может создать трассировку, несколько спанов фреймворка, две генерации, пять спанов инструментов, запись сессии и несколько оценок. Одни облачные продукты берут плату за трассировки или спаны, другие за события или принятые единицы, а широкие системы мониторинга могут учитывать проиндексированные журналы, хосты или объем данных. Например, документация Langfuse определяет принятую единицу как трассировку, наблюдение или оценку. Оперативная оценка может добавить результат и еще один вызов модели. Функция, улучшающая видимость, одновременно увеличивает расходы на телеметрию и модель.

У хранения две цены. Поставщик берет деньги за данные и запросы, а ваша команда принимает риск приватности при сохранении содержимого. Если для анализа инцидентов не нужен текст, держите доступные для поиска метаданные дольше исходных промптов. Сохраняйте выбранные неудачные трассировки и оцененные примеры для наборов регрессионных тестов. Не храните каждый документ клиента вечно только потому, что во время пилота место стоило дешево.

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

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

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

В тест кандидатов стоит включить плохой релиз

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

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

1. Запустите исправную базовую версию и убедитесь, что трассировка содержит все ожидаемые родительские и дочерние спаны.
2. Выпустите изменение поиска, которое возвращает правдоподобный, но устаревший документ, затем проверьте, что оценщик качества фиксирует провал при нормальных HTTP и задержке.
3. Вызовите одну повторную попытку модели и одну повторную попытку платного инструмента, затем сверьте их стоимость с исходными записями поставщиков.
4. Проведите процесс через очередь и убедитесь, что клиент, релиз, версия промпта и контекст трассировки дошли до обработчика.
5. Попросите незнакомого с системой инженера за ограниченное время найти регрессию, затронутую группу, лишние расходы и исходные данные.

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

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

Победителями могут стать два продукта с узкими границами. Helicone вместе со спанами приложения способен охватить экономику шлюза и внутреннюю логику. Phoenix или Langfuse могут хранить открытые трассировки и оценки, пока Datadog отвечает за инфраструктурные инциденты. LangSmith может дать кратчайший путь команде с большим объемом LangGraph, которой нужны трассировка и оценка в одном процессе. Соответствие архитектуре важнее универсального рейтинга.

Владение важнее еще одной панели

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

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

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

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

Не отправляйте срочное оповещение по каждому любопытному показателю. Будите человека, если он может действовать сейчас: при скачке расходов, устойчивом провале задач, остановке экспортера или регрессии проверки безопасности. Медленные изменения отправляйте на еженедельный разбор, где продуктовая и инженерная команды изучат группы и добавят неудачные примеры в наборы регрессионных тестов. Усталость от предупреждений приучит команду игнорировать именно тот сигнал, который однажды понадобится.

Во время Team & AI Audit, который я провожу через oleg.is, я ищу такой разрыв ответственности, потому что дорогая работа с ИИ часто прячется в повторных попытках, дублирующих проверках и инструментах, которым никто не доверяет. Выбранная система наблюдаемости должна уменьшать эту неопределенность, а не создавать еще одну систему, для толкования которой нужен комитет.

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