Copy English

Why

A conventional dashboard is built around one HTTP request and one HTTP response — status code, latency, maybe a payload size. A multi-agent or LLM pipeline hides its real failures inside that single green checkmark: a tool call that silently returned nothing, a slow database step that ate the latency budget without tripping any alert, a prompt that grew past its context limit, or an answer that would come out differently on a retry with the exact same input. None of these fail the HTTP check. All four turn a working-looking system into one that quietly gives wrong, inconsistent, or non-compliant answers, and in a regulated domain — the video's example is loan underwriting — an unreproducible decision is itself a compliance problem, not just a bug. Closing this gap needs two different capabilities: enough recorded detail to reconstruct what actually happened inside a request (tracing), and a way to score whether what happened was correct (evaluation) — run continuously, not just when something visibly breaks.

How it works

Four silent failures

• Silent tool failures (03:00): an MCP server or tool call returns empty or malformed data, and the agent has no way to notice, so it answers anyway, plausibly and wrongly.
• Cascading latency (03:16): a slow downstream query — a database call, say — inflates the LLM call and the total response time, but nothing in a flat HTTP view says which hop was the bottleneck.
• Context overflow (03:22): too much data gets stuffed into a prompt, and the call fails or times out with no clear signal pointing back at the prompt-construction step.
• Non-determinism (03:40): identical input produces different output across runs, which breaks reproducibility and, in a regulated domain, breaks compliance review.

Traces and spans

A trace is the full record of one request from start to finish; a span is one step inside it — a single LLM call, a tool execution, a database query — and spans nest into a parent-child tree that renders as a visual timeline (04:04–04:21). Each span carries its inputs and outputs, latency, token consumption, and (for tool calls) the parameters passed in. Tagging a trace with a user ID and session ID lets an engineer replay the exact decision path of one problem session instead of guessing from aggregate metrics. Because MLflow Tracing is built on the OpenTelemetry standard, the same trace data can be dual-exported to tools like Jaeger or Grafana Tempo (08:13). Instrumentation is close to free for common frameworks — mlflow.langchain.autolog() captures LangChain/LangGraph traces automatically — and a @mlflow.trace decorator covers custom code paths (08:43).

Grading what the trace shows

Two evaluation styles sit on top of the trace data. Deterministic scoring covers anything checkable by a rule: regex matches, exact-match comparisons, latency thresholds (05:01). LLM-as-a-judge hands the trace to a separate model whose only job is to grade the output (05:16), against criteria such as: did the agent pick the right tool (tool-call correctness); did it solve the task in a minimal number of steps (tool-call efficiency); was the answer relevant; was it safe; did it follow a stated guideline, such as "be helpful but never promise a fixed interest rate" (05:24). Rules simple enough to write as a regex should stay a regex — the judge model is for judgment calls a rule can't express.

Prompt registry

Verified system prompts get version control comparable to a Git history — with an audit trail and the ability to roll back a prompt that regresses (06:10). This turns "we changed the prompt" from an untracked edit into a reviewable, revertible change with the same discipline as a code change.

Four things production needs

1. A real backend. The default local file store breaks under concurrent writes; production wants a PostgreSQL/MySQL backend, object storage for trace artifacts, and an OAuth proxy in front (06:23).
2. Async logging plus sampling. Trace writes go out in the background so they never block the response path; under high traffic, sample ordinary requests but keep collecting 100% of errors (06:57).
3. A judge-model strategy with a cost budget. An air-gapped environment needs its own judge endpoint; cost scales as evaluation-set size times number of judges, so route anything rule-shaped to a regex instead of a judge call (07:22).
4. Evaluation in CI. Run mlflow.genai.evaluate as a quality gate — the same way a unit test runs — whenever a prompt or agent's logic changes, so a regression is caught before merge, not after a user hits it (07:56).

Where it lands in Jayverse

• Rabbit: trace every mandate execution. Which tool calls led to a submitted transaction is exactly the record the Auditor's rule needs made concrete — a mandate span tree with an Interrupted state or an empty-tool-response state should be a first-class, queryable case, not something read off logs after the fact.
• Verex: the resolution pipeline is a trace, not a log line. Which source was queried, which benchmark or venue price it returned, and which rule picked the final resolution value belongs in a span tree tagged by market ID, so a disputed resolution can be replayed exactly as it happened.
• CI with frozen lockfiles: add an evaluation job. mlflow.genai.evaluate as a merge gate on prompt or agent-logic changes is the same shape as Dark Horse (e)'s "boundary files before agent tasks" — both are about stopping a bad change at the gate instead of catching it in production.
• Theory: non-determinism and sampling are the same problem as elsewhere. Same input, different output, on every run is a scheduling/queueing-adjacent reliability question, and the "sample normal traffic, keep 100% of errors" rule is a specific instance of a general triage pattern worth a Theory entry of its own.
• Eng: interview vocabulary. Trace, span, and judge (as in LLM-as-a-judge) are now standard terms for describing observability work in a systems-design interview; worth having ready in English, not just recognized in Korean translation.

Verified and unverified

Verified on 2026-09-19: MLflow is a real open-source machine learning lifecycle platform (originally from Databricks, now under the Linux Foundation); MLflow Tracing is built on the OpenTelemetry standard and ships autolog integrations plus a @mlflow.trace decorator for custom instrumentation; mlflow.genai.evaluate and LLM-as-a-judge scorers exist as part of MLflow 3; a prompt registry with versioning exists; and MLflow's default tracking backend is a local file store, with production deployments expected to run a database backend instead. Taken from the video summary and not independently checked: the specific timestamps, the exact wording of the four silent-failure categories and the four production requirements as the video states them, the dual-export claim to Jaeger and Grafana Tempo, the cost formula (evaluation-set size times judge count), and the loan-underwriting example.

Sources: YouTube — IBM Technology, "What Is MLflow? Tracing AI Agents & LLM Workflows" · MLflow project documentation (mlflow.org) · related items: Tech #62 (agentic engineering writes the boundaries), the AI-engineer item (key ai-engineer-builds-the-car; its Tier 3 is observability), Dark Horse (e).

← All Knowledge Notes · Workspace Index · Top ↑

Copy 한국어

MLflow Tracing — 대시보드의 200 OK는 에이전트가 맞는 답을 냈다는 증거가 아니다

IBM Technology 유튜브 채널이 "What Is MLflow? Tracing AI Agents & LLM Workflows"라는 영상에서 멀티 에이전트·LLM 시스템을 위한 관측성(observability)과 평가를 다룬다. 도입부 주장은 이렇다. HTTP 모니터링 대시보드는 200 OK와 적정 응답 시간을 보여줄 수 있지만, 사용자는 여전히 엉뚱한 답을 받았을 수 있다. 표준 인프라 지표는 요청 안쪽을 들여다보지 않기 때문이다(00:39). 영상은 멀티 에이전트 시스템에 특유한 네 가지 침묵형 장애를 꼽은 다음, 기록 계층으로서 MLflow Tracing(OpenTelemetry 기반)을, 채점 계층으로서 LLM-as-a-judge를 설명하고, 마지막으로 이 모든 것을 프로덕션에서 돌리기 전에 필수라고 주장하는 네 가지 설정을 짚는다.

Jayverse에서 이것은 Auditor 행이 이미 하고 있는 일의 나머지 절반이다. Auditor는 무엇을 어떤 규칙으로 확인했는지 진술하는데, 트레이싱과 평가는 Auditor가 대조할 증거 자체를 만드는 메커니즘이고, CI 게이트는 그 증거가 병합 전에 강제되는 지점이다.

왜

기존 대시보드는 HTTP 요청 하나와 응답 하나를 중심으로 만들어진다. 상태 코드, 지연, 많아야 페이로드 크기. 멀티 에이전트나 LLM 파이프라인은 실제 장애를 그 초록색 체크 표시 하나 뒤에 숨긴다. 도구 호출이 조용히 빈 데이터를 돌려주거나, 느린 데이터베이스 단계가 지연 예산을 다 써버리면서도 어떤 알람도 울리지 않거나, 프롬프트가 컨텍스트 한도를 넘어 자라거나, 같은 입력인데 재시도하면 다른 답이 나오거나. 이 네 가지 모두 HTTP 검사는 통과한다. 넷 다 겉보기엔 정상 작동하는 시스템을 조용히 틀리거나 일관성 없거나 규정을 어기는 답을 내는 시스템으로 바꿔 놓고, 규제 도메인 — 영상의 예시는 대출 심사다 — 에서는 재현 불가능한 결정 자체가 버그가 아니라 컴플라이언스 문제다. 이 틈을 메우려면 서로 다른 두 능력이 필요하다. 요청 안에서 실제로 무슨 일이 있었는지 재구성할 만큼 충분히 기록하는 것(트레이싱), 그리고 그 일이 맞았는지 채점하는 방법(평가) — 무언가 눈에 띄게 터졌을 때만이 아니라 계속 돌아가야 한다.

동작 방식

네 가지 침묵형 장애

• Silent tool failures(03:00): MCP 서버나 도구 호출이 빈 데이터나 형식이 깨진 데이터를 돌려줘도 에이전트는 알아챌 방법이 없어서, 그럴듯하지만 틀린 답을 낸다.
• Cascading latency(03:16): 느린 하위 쿼리(예: DB 호출)가 LLM 호출과 전체 응답 시간을 부풀리지만, 평평한 HTTP 뷰만으로는 어느 구간이 병목인지 알 수 없다.
• Context overflow(03:22): 프롬프트에 과도한 데이터가 들어가면서 호출이 실패하거나 타임아웃되는데, 원인이 프롬프트 구성 단계라는 신호는 어디에도 없다.
• Non-determinism(03:40): 같은 입력인데 실행마다 다른 출력이 나온다. 재현성이 깨지고, 규제 도메인에서는 컴플라이언스 심사가 깨진다.

트레이스와 스팬

트레이스(trace)는 요청 하나가 시작부터 끝까지 처리되는 전체 기록이고, 스팬(span)은 그 안의 한 단계 — 단일 LLM 호출, 도구 실행, DB 쿼리 — 이며, 스팬들은 부모-자식 트리로 중첩되어 시각적 타임라인으로 나타난다(04:04–04:21). 각 스팬은 입출력, 레이턴시, 토큰 소비, (도구 호출이면) 전달된 매개변수를 담는다. 트레이스에 사용자 ID와 세션 ID를 태깅해 두면 집계 지표로 추측하는 대신 문제가 생긴 특정 세션의 결정 경로를 정확히 리플레이할 수 있다. MLflow Tracing이 OpenTelemetry 표준 위에 있기 때문에, 같은 트레이스 데이터를 Jaeger나 Grafana Tempo 같은 도구로 이중 익스포트할 수 있다(08:13). 흔한 프레임워크라면 계측이 거의 공짜에 가깝다 — mlflow.langchain.autolog()가 LangChain/LangGraph 트레이스를 자동으로 캡처하고, 커스텀 코드 경로는 @mlflow.trace 데코레이터로 덮는다(08:43).

트레이스가 보여주는 것을 채점하기

트레이스 데이터 위에 두 가지 평가 방식이 있다. 결정론적 점수(deterministic scoring)는 규칙으로 검사 가능한 모든 것을 다룬다 — 정규식 일치, 정확 일치 비교, 레이턴시 임계값(05:01). LLM as a Judge는 트레이스를, 출력을 채점하는 것만이 일인 별도의 모델에 넘긴다(05:16). 기준은 이렇다. 에이전트가 맞는 도구를 골랐는가(도구 호출 정확도), 최소 단계로 문제를 풀었는가(도구 호출 효율성), 답이 관련성 있는가, 안전한가, 명시된 가이드라인을 따랐는가 — 예를 들어 "친절하되 금리를 확정 약속하지 말 것"(05:24). 정규식으로 표현될 만큼 단순한 규칙은 정규식으로 남겨야 한다. Judge 모델은 규칙이 표현할 수 없는 판단이 필요한 자리에 쓴다.

Prompt Registry

검증된 시스템 프롬프트가 Git 히스토리에 준하는 버전 관리를 받는다 — 감사 추적과, 성능이 나빠진 프롬프트를 되돌릴 수 있는 능력과 함께(06:10). 이는 "프롬프트를 바꿨다"를 추적되지 않는 수정에서, 코드 변경과 같은 수준의 규율로 리뷰하고 되돌릴 수 있는 변경으로 바꾼다.

프로덕션이 요구하는 네 가지

1. 제대로 된 백엔드. 기본 로컬 파일 스토리지는 동시 쓰기에서 깨진다. 프로덕션은 PostgreSQL/MySQL 백엔드, 트레이스 아티팩트용 오브젝트 스토리지, 앞단의 OAuth 프록시를 원한다(06:23).
2. 비동기 로깅과 샘플링. 트레이스 쓰기는 백그라운드로 나가서 응답 경로를 절대 막지 않는다. 트래픽이 많으면 일반 요청은 샘플링하되 에러는 100% 수집한다(06:57).
3. 비용 예산이 딸린 judge 모델 전략. 폐쇄망 환경은 자체 judge 엔드포인트가 필요하다. 비용은 평가셋 크기 곱하기 judge 수로 커지므로, 규칙 모양의 것은 judge 호출 대신 정규식으로 보낸다(07:22).
4. CI 안의 평가. 프롬프트나 에이전트 로직이 바뀔 때마다 mlflow.genai.evaluate를 단위 테스트처럼 품질 게이트로 실행해서, 회귀가 사용자에게 닿기 전에 병합 전 단계에서 걸리게 한다(07:56).

Jayverse에서의 위치

• Rabbit: 모든 mandate 실행을 트레이스하라. 어떤 도구 호출이 제출된 트랜잭션으로 이어졌는지는 Auditor의 규칙이 정확히 필요로 하는 기록이다. Interrupted 상태나 도구 응답이 빈 상태를 사후에 로그에서 읽어내는 대신, 마디마다 조회 가능한 1급 케이스로 만든 mandate 스팬 트리로 남겨야 한다.
• Verex: 정산 파이프라인은 로그 한 줄이 아니라 트레이스다. 어느 소스를 조회했는지, 어느 벤치마크나 거래소 가격이 돌아왔는지, 어느 규칙이 최종 정산값을 골랐는지가 마켓 ID로 태깅된 스팬 트리에 있어야, 분쟁이 붙은 정산을 일어난 그대로 정확히 리플레이할 수 있다.
• 동결된 lockfile을 쓰는 CI: 평가 작업을 추가하라. 프롬프트나 에이전트 로직 변경에 mlflow.genai.evaluate를 병합 게이트로 거는 것은 Dark Horse (e)의 "에이전트 작업 전에 경계 파일" 과 같은 모양이다. 둘 다 나쁜 변경을 프로덕션에서 잡는 대신 게이트에서 막는 이야기다.
• Theory: 비결정성과 샘플링은 다른 곳과 같은 문제다. 같은 입력, 매 실행 다른 출력은 스케줄링·큐잉에 가까운 신뢰성 질문이고, "일반 트래픽은 샘플링하고 에러는 100% 수집한다"는 규칙은 더 일반적인 트리아지 패턴의 구체적 사례로 Theory 항목 하나를 받을 만하다.
• Eng: 인터뷰 어휘. Trace, span, judge(LLM-as-a-judge에서의)는 이제 시스템 설계 인터뷰에서 관측성 작업을 설명하는 표준 용어다. 한국어로 이해하는 것을 넘어 영어로 바로 나와야 한다.

확인된 것과 미확인

2026-09-19 확인: MLflow는 실재하는 오픈소스 머신러닝 라이프사이클 플랫폼이다(원래 Databricks에서 시작해 지금은 Linux Foundation 산하). MLflow Tracing은 OpenTelemetry 표준 위에 만들어졌고 autolog 통합과 커스텀 계측용 @mlflow.trace 데코레이터를 제공한다. mlflow.genai.evaluate와 LLM-as-a-judge 스코어러는 MLflow 3의 일부로 존재한다. 버전 관리가 되는 prompt registry가 존재한다. MLflow의 기본 트래킹 백엔드는 로컬 파일 스토리지이고, 프로덕션 배포는 데이터베이스 백엔드를 쓰는 것이 기대된다. 영상 요약에서 가져왔고 독립 확인하지 않은 것: 정확한 타임스탬프, 영상이 말한 네 가지 침묵형 장애와 네 가지 프로덕션 요구사항의 정확한 표현, Jaeger·Grafana Tempo로의 이중 익스포트 주장, 비용 공식(평가셋 크기 곱하기 judge 수), 대출 심사 예시.

출처: YouTube — IBM Technology, "What Is MLflow? Tracing AI Agents & LLM Workflows" · MLflow 프로젝트 문서(mlflow.org) · 관련 항목: Tech #62(에이전틱 엔지니어링은 경계를 쓴다), AI-engineer 항목(키 ai-engineer-builds-the-car, 그 Tier 3가 observability), Dark Horse (e).

← 전체 기술 노트 · 워크스페이스 인덱스 · 맨 위 ↑