analyzing-mlflow-trace

Analyzing MLflow Trace — официальный навык для расследования одного MLflow trace, когда нужно понять ошибку, качество, поведение GenAI-приложения или причину неожиданного результата. Trace представляется деревом spans: каждый span описывает операцию вроде LLM-вызова, tool invocation или retrieval step и содержит входы, выходы, время и статус. В trace также могут быть assessments — отзывы человека или LLM-судьи о качестве. Такое представление позволяет отделять общий результат выполнения от конкретного места, где возникло расхождение. Для начала источник рекомендует получить полный JSON trace командой mlflow traces get --trace-id <ID> и обязательно перенаправить вывод в файл: сложный trace может занимать 100 KB и более, а прямой pipe в jq, head или другой процесс способен молча дать неполный или пустой вывод. После сохранения файл разбирается обычными JSON-инструментами. Верхний уровень содержит info с trace_id, state, request_time и assessments, а data содержит spans. Полезные пути включают .info.state, .data.spans, корневой span без parent_span_id, status.code, status.message и сериализованные JSON-атрибуты mlflow.spanInputs и mlflow.spanOutputs. Быстрый health check собирает state, число spans, spans со STATUS_CODE_ERROR и ошибки assessments. Но state: OK означает только отсутствие необработанного исключения, а не правильность ответа. Если assessments есть, сначала нужно прочитать rationale: одно и то же value может иметь разный смысл в зависимости от настройки scorer. Ошибка assessment — это сбой судьи или scorer, а не обязательная ошибка trace. Если assessments отсутствуют, анализ переходят к входам, выходам и промежуточным данным spans; если поля отличаются из-за стороннего OpenTelemetry-клиента, нужно исследовать реальный словарь attributes, а не предполагать стандартные имена. После сигнала о проблеме spans помогают найти место расхождения. Дерево обычно отражает call stack: parent span вызвал child span, имена могут соответствовать функциям с @mlflow.trace или mlflow.start_span(), а для autologging — соглашениям LangChain, OpenAI и других фреймворков. Сопоставление входов и выходов span с кодом показывает, почему произошло наблюдаемое поведение. Например, корректный выбор поиска и успешный ответ LLM могут скрывать, что retriever вернул нерелевантный документ; тогда первопричина находится в retrieval/index, а не в генерации. При оценке производительности учитываются интервалы между parent и child spans, повторяющиеся имена как возможный сигнал retry и длительность отдельных операций. Token usage в trace metadata или span attributes помогает объяснить задержку и стоимость, но такие данные есть не у всех клиентов. Навык не заменяет чтение актуальной схемы references/trace-structure.md, не обещает одинаковые поля для всех версий MLflow и не превращает статус OK в доказательство качества. Его результат — проверяемая гипотеза о том, где и почему trace отклонился от ожидания, которую затем нужно сопоставить с кодом и исправить в соответствующем компоненте.