4.4시스템 문제 진단

진단의 출발점은 "무엇이 바뀌었는가"입니다. 잘 되던 시스템이 나빠졌다면 무언가 변했고, 변한 것의 목록이 곧 후보 목록입니다.

바뀔 수 있는 것은 네 갈래뿐입니다.

1. 입력 — 사용자 질의의 분포, 업로드 문서, 외부 데이터
2. 프롬프트·도구 정의 — 시스템 프롬프트, 도구 설명, 스키마
3. 모델 — 버전, 등급, 파라미터
4. 주변 시스템 — 검색 인덱스, 데이터베이스, 외부 API

진단의 첫 질문은 언제나 "이 넷 중 무엇이 최근에 바뀌었는가" 입니다. 배포 이력과 데이터 갱신 이력을 나란히 놓고 증상 발생 시점과 대조하면 후보 대부분이 즉시 탈락합니다.

바뀐 것이 없는데 증상이 나타났다면, 실은 입력 분포가 바뀐 것인 경우가 대부분입니다. 새 고객군이 유입되었거나, 계절적 질의가 들어오거나, 상류 서비스가 다른 형식으로 데이터를 보내기 시작한 것입니다. 이 경우 로그에서 증상 발생 전후의 입력을 표본으로 뽑아 비교하는 것이 가장 빠릅니다.

시험에서는 증상과 함께 "무엇은 그대로였다"는 단서가 주어집니다. 그 단서가 후보를 지우는 장치이므로, 변하지 않았다고 명시된 것을 원인으로 고르는 선택지는 대개 오답입니다.

세 가지는 겉으로 비슷해 보이지만 판별 신호가 다릅니다.

증상	프롬프트 실패	검색 실패	모델 불일치
형식이 자주 어긋남	유력	낮음	가능(등급 하향 시)
근거는 맞는데 결론이 틀림	유력	낮음	가능
자신 있게 사실이 아닌 내용	가능	유력	낮음
특정 주제만 나쁨	낮음	유력	낮음
전반적으로 조금씩 나쁨	가능	낮음	유력

판별의 핵심은 모델에 실제로 들어간 입력을 직접 보는 것입니다. RAG 시스템에서 답이 틀렸을 때, 검색이 가져온 근거를 눈으로 확인하면 두 경우가 즉시 갈립니다. 근거가 엉뚱하면 검색 문제이고, 근거는 정확한데 답이 틀렸으면 생성 단계 문제입니다.

# 진단용 덤프: 모델이 실제로 본 것을 그대로 남긴다
def answer_with_trace(query):
    chunks = retrieve(query)
    prompt = build_prompt(query, chunks)
    result = generate(prompt)
    return {
        "answer": result.text,
        "retrieved_ids": [c.id for c in chunks],
        "retrieved_text": [c.text[:300] for c in chunks],  # 근거 원문
        "prompt_tokens": result.usage.input_tokens,
    }

이 덤프가 없으면 진단은 추측이 됩니다. 근거를 눈으로 확인하지 않고 프롬프트부터 고치는 것이 실무에서 가장 흔한 시간 낭비입니다. 요강의 샘플 문항도 정확히 이 지점을 묻습니다. 문서 갱신 직후 자신 있게 틀린 답이 나오고 모델과 지연시간이 그대로라면, 먼저 볼 곳은 검색과 인덱싱입니다.

환각(hallucination)을 한 덩어리로 다루면 대응이 뭉툭해집니다. 유형을 나누면 처방이 달라집니다.

• 근거 부재형 — 참고할 정보가 컨텍스트에 없는데 답을 지어냅니다. 대응은 "모르면 모른다고 답하라"는 명시적 허용과, 근거 없는 답변을 거르는 검증 단계입니다.
• 근거 왜곡형 — 근거는 있는데 잘못 읽거나 과장합니다. 대응은 인용 요구입니다. 답변에 근거 문장을 함께 제시하게 하면 왜곡이 눈에 띕니다.
• 오래된 정보형 — 모델의 사전 지식이 최신 사실을 덮어씁니다. 대응은 검색 결과를 우선하라는 지시와, 사전 지식에만 의존한 답을 표시하게 하는 것입니다.
• 형식 환각 — 존재하지 않는 필드나 도구를 지어냅니다. 대응은 구조화된 출력과 스키마 검증입니다.

Anthropic 문서는 환각을 줄이는 기법으로 모르면 모른다고 답할 여지를 주는 것, 근거를 인용하게 하는 것, 그리고 답변을 다시 검증하게 하는 것을 제시합니다. 여기서 중요한 점은 프롬프트 기법만으로 환각을 0으로 만들 수는 없다는 것입니다. 정확도가 중요한 경로에는 출력 검증이나 사람 검토 같은 시스템 수준 장치가 함께 있어야 합니다.

시험 함정으로 "온도를 0으로 낮추면 환각이 사라진다"는 선택지가 나옵니다. 온도를 낮추면 출력이 결정적으로 변할 뿐, 근거가 없는 상태에서 지어내는 성향 자체가 없어지지는 않습니다.

후보가 좁혀졌으면 마지막 단계는 확정입니다. 확정의 도구는 최소 재현 사례(minimal reproduction) 입니다.

절차는 다음과 같습니다.

1. 실패한 요청 하나를 그대로 재현한다. 같은 입력에 같은 실패가 나오는지 확인한다.
2. 재현되면 한 번에 하나씩 요소를 제거하거나 바꿔 본다. 검색 결과를 정답 근거로 교체해 보고, 프롬프트를 이전 버전으로 되돌려 보고, 모델을 이전 버전으로 바꿔 본다.
3. 실패가 사라지는 지점이 원인이다.
4. 재현되지 않으면 결정성 문제이므로, 같은 입력을 여러 번 돌려 실패율을 먼저 측정한다.

4번을 건너뛰는 것이 흔한 실수입니다. 한 번 돌려 보고 정상이라고 판단하면, 재현율 20%짜리 문제를 고쳤다고 오해하게 됩니다. 비결정적 실패는 확률로 다뤄야 합니다.

# 결정성 확인: 같은 입력을 반복해 실패율을 잰다
fails = 0
for _ in range(20):
    out = run(case.input)
    if not passes(out, case.expected):
        fails += 1
print(f"failure rate: {fails}/20")

원인이 확정되면 그 사례를 회귀 데이터셋에 넣습니다. 고친 뒤 같은 문제가 다시 나타나는지 자동으로 잡히게 만드는 것이 진단의 마지막 단계입니다.