"RAG 핵심 학습 (16/26) — 실험 자동화: LangSmith / Phoenix / MLflow"

RAG 개선은 기억으로 관리하면 반드시 다시 무너진다. 실험은 기록되고 비교돼야 한다.

retriever 파라미터를 바꾸고, reranker를 붙이고, prompt를 바꾸고, chunk 크기를 조정하면 체감상 좋아질 수 있다. 그러나 어느 변경이 실제 효과였는지 남지 않으면 같은 실수를 반복한다. 이번 글은 RAG 실험을 버전, 실행 로그, 평가 결과, 추론 trace로 남기는 방법을 다룬다. 도구는 달라도 핵심은 같다. "질문-근거-답-점수"를 한 묶음으로 추적해야 한다.

0. Prerequisites

14편 평가셋
15편 검색 지표
13편 reranker

1. 학습 목표

실험 자동화가 왜 필요한지 설명한다.
LangSmith, Phoenix, MLflow의 역할 차이를 구분한다.
RAG 실험 단위를 어떻게 버전 관리할지 안다.
추론 trace와 평가 결과를 연결하는 이유를 이해한다.

2. 핵심 요약

RAG 실험 자동화의 목적은 "나중에 다시 같은 실험을 재현할 수 있게 하는 것"이다. 이를 위해 질문셋 버전, 코퍼스 버전, 인덱스 버전, prompt 버전, 모델 버전, 평가 결과를 함께 저장해야 한다. LangSmith는 LLM 앱 trace와 실험 실행 관리에 강하고, Phoenix는 observability와 eval 시각화에 강하며, MLflow는 범용 실험 버전 관리에 강하다. 중요한 것은 도구 선택보다 기록 단위다. 질문 하나의 실패를 나중에 재현할 수 있어야 한다.

3. 직관 — 왜 "지난주엔 좋았는데"가 반복되는가

RAG 시스템은 작은 변경이 많다.

chunk size 400 → 600
reranker on/off
prompt 지시문 수정
embedding 모델 교체

이 변경들이 누적되면 어느 것이 성능 변화 원인인지 알기 어렵다. 실험 자동화는 "무엇을 바꿨고, 어떤 질문에서, 어떤 근거를 가져왔고, 점수가 어떻게 달라졌는지"를 남겨 이 혼란을 줄인다.

4. 정의 — 실험 자동화의 기본 단위

항목	의미
Run	한 번의 실험 실행 기록
Trace	질문 입력부터 retrieval, rerank, answer 생성까지의 단계 로그
Artifact	평가 리포트, 인덱스 설정, 샘플 답변 등 결과물
Dataset Version	평가 질문셋의 버전
Prompt Version	프롬프트 템플릿 버전
Corpus / Index Version	문서 집합과 인덱스 상태의 버전

5. 구조 — 무엇을 반드시 같이 저장해야 하는가

최소한 다음 여섯 가지는 함께 가야 한다.

질문셋 버전
코퍼스 또는 인덱스 버전
retrieval 설정
generation 설정
trace 샘플
metric 결과

이 중 하나라도 빠지면 "점수가 왜 바뀌었는지"를 나중에 설명하기 어려워진다.

6. 원리 워크스루 — 한 실험 Run의 형태

6.1 MLflow 스타일 로그

with mlflow.start_run(run_name="hybrid_rerank_v3"):
    mlflow.log_param("embedding_model", "bge-m3")
    mlflow.log_param("reranker", "bge-reranker-v2-m3")
    mlflow.log_param("chunk_size", 600)
    mlflow.log_param("top_k", 20)

    metrics = evaluate_pipeline(eval_dataset)
    mlflow.log_metrics(metrics)

6.2 Trace를 함께 남기기

trace = {
    "question": question,
    "retrieved_ids": retrieved_ids,
    "reranked_ids": reranked_ids,
    "final_answer": answer,
    "faithfulness": score["faithfulness"],
}
save_trace(trace)

6.3 LangSmith / Phoenix가 빛나는 지점

질문 하나를 클릭했을 때, - 어떤 문서를 회수했는지 - 어느 단계에서 순서가 바뀌었는지 - 최종 답변이 무엇이었는지

를 한 화면에서 볼 수 있어야 한다. 그래야 점수 하락의 원인을 추적할 수 있다.

자기 설명: metric만 저장하고 trace를 안 남기면 왜 문제인지 한 문장으로 답해 보라.

7. 변형과 사례

7.1 LangSmith — LLM 앱 추적 중심

무엇이 바뀌는가
질문별 실행 흐름이 세밀하게 기록된다.

왜 등장했는가
LLM 파이프라인은 함수 호출 몇 개가 아니라 연쇄 단계이기 때문이다.

무엇이 가능해졌는가
retrieval, prompt, output을 질문 단위로 한눈에 비교할 수 있다.

한계와 다음 단계
실험 메타데이터 전체 관리에서는 MLflow 같은 범용 도구가 더 편할 수 있다.

7.2 Phoenix — observability와 eval 시각화

trace 탐색, hallucination 관찰, eval 결과 비교에 강하다. 모델 품질 감시와 디버깅 흐름이 좋은 편이다.

7.3 MLflow — 범용 실험 관리

LLM 특화는 아니지만, run, params, metrics, artifacts를 체계적으로 보관하는 데 강하다. 기존 MLOps 스택과 잘 맞는다.

8. 한계와 실패 양상

8.1 도구만 넣고 규칙이 없으면 기록이 쌓이기만 한다

"run_name 규칙", "dataset version 규칙", "baseline 유지 규칙"이 없으면 나중에 비교가 불가능하다.

8.2 과도한 로깅은 비용과 복잡도를 늘린다

모든 프롬프트, 모든 문맥, 모든 토큰을 무제한 저장하면 저장비와 개인정보 이슈가 커진다.

8.3 사람 해석이 빠지면 숫자만 남는다

metric이 하락한 이유를 인간 언어로 적은 실험 노트가 없으면 팀 학습이 잘 남지 않는다.

8.4 다음 단계 — 이제 질문 자체를 분류해야 한다

실험 자동화가 갖춰지면, 성능 차이가 어느 질문 유형에서 나는지 보고 싶어진다. 17편은 query classification이다.

8.5 입문자가 자주 빠지는 함정 5선

#	함정	증상	빠른 점검
1	dataset version 미기록	과거 실험 재현 불가	버전 문자열 강제
2	trace 없는 metric 로그	원인 추적 불가	질문별 trace 저장
3	baseline 없이 계속 변경	개선 여부 불명	기준 run 고정
4	run naming 규칙 부재	비교 화면 혼란	naming convention 작성
5	privacy 고려 없는 로그	보안 리스크	민감 데이터 마스킹

9. 정리된 결론 — 보지 않고 답해 보라

Q1. 실험 자동화의 핵심 목적은?

정답 변경과 성능 차이를 재현 가능하게 기록하는 것이다.
왜 RAG는 작은 변경이 많아 기억에 의존하면 원인을 잃기 쉽기 때문이다.

Q2. metric만 저장하면 왜 부족한가?

정답 왜 그런 점수가 나왔는지 질문 단위 원인을 알 수 없기 때문이다.
왜 retrieval, rerank, answer trace가 함께 있어야 디버깅이 가능하다.

Q3. LangSmith와 MLflow의 차이는?

정답 LangSmith는 LLM 실행 trace에, MLflow는 범용 실험 버전 관리에 더 강하다.
왜 도구의 기본 철학과 인터페이스가 다르기 때문이다.

Q4. 실험 자동화 전에 정해야 할 최소 규칙은?

정답 dataset version, run naming, baseline 관리 규칙이다.
왜 도구보다 비교 가능성이 먼저이기 때문이다.

Cheat Sheet — 이 편의 식·정의 1페이지

정의 - Run: 한 번의 실험 실행 - Trace: 질문부터 답까지 단계 로그 - Artifact: 리포트, 샘플 답변, 설정 파일

최소 코드

mlflow.log_param("chunk_size", 600)
mlflow.log_metrics({"mrr": 0.71, "recall_at_10": 0.92})

언제 무엇을 | 상황 | 도구 | |---|---| | 질문별 trace 탐색 | LangSmith / Phoenix | | 범용 실험 버전 관리 | MLflow | | hallucination 관찰 | Phoenix | | 체계적 baseline 비교 | MLflow + eval suite |

참고 자료

공식 docs

LangSmith docs
Arize Phoenix docs
MLflow tracking docs

보조 자료

사용자 노트 13장 실험 자동화

다음 편으로 이어지는 흐름

실험을 기록할 수 있게 되면 다음 질문은 이것이다. "어떤 질문 유형에서 성능이 무너지는가?" 다음 17편에서는 질문을 정의, 비교, 절차, 고유명사, 시점 의존 같은 유형으로 나누는 query classification을 다룬다.

이 블로그 검색

MaJu's Note