В трассе LLM нет вызова инструмента: как искать разрыв контекста

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

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

Разбор на примере

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

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

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

Порядок диагностики

Отправьте один контрольный запрос с известными этапами и проследите его через все сервисы. Сравните метки времени и журналы исполнителя. Отдельно проверьте повторную доставку задачи и параллельные ветки: они не должны сливаться в один неразличимый вызов.

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

Что этот способ не гарантирует

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

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

Если хотите связать этот разбор с системной практикой, посмотрите программу LLMOps & Evaluation на Latorn: она охватывает контур оценки, версии промптов, мониторинг и выпуск LLM-приложений. Перед оплатой сопоставьте требования курса со своим опытом и задачей проекта.

Следующий шаг: LLMOps: измерение качества, расходы и выпуск изменений. По смежным вопросам: Тайм-ауты в LLM-eval: как не улучшить метрику удалением неудачных ответов, Утечка в LLM-eval: почему перефразы одного вопроса нельзя считать независимыми тестами.