Triage-and-Voice: LLM 환각 수정

LLM 환각 현상 제거를 위한 트라이아지-보이스 아키텍처 패턴

챗봇의 LLM이 대화를 분석하고 실제 핫라인 번호 대신 아동 상담 전화번호를 지어내는 경우가 있습니다. "연락처를 지어내지 마세요"라는 지시는 무시됩니다. 그 이유는 단일 패스에서의 작업 충돌 때문입니다: 정확한 분석과 공감적 응답이 토큰을 두고 경쟁하며, 중요한 데이터에서 환각 현상을 일으킵니다.

단일 패스 아키텍처의 문제점

표준 LLM 제품 구조에서는 사용자 입력이 모델로 직접 전달되어 최종 답변을 생성합니다. 분석은 참여자, 위험, 목표 등 정확한 사실을 담은 구조화된 JSON 출력이 필요합니다. 응답을 구성하는 것은 음성과 어조를 포함한 창의적인 작업입니다.

이 둘을 단일 프롬프트로 결합하면 타협이 발생합니다:

• 모델은 스타일을 위해 정확성을 희생합니다.
• 환각 현상이 설득력 있는 텍스트로 위장됩니다.
• 사실과 허구를 프로그래밍적으로 구분하는 것이 불가능합니다.

모델 성능 향상(추론 모델, 더 많은 토큰)은 오류 빈도를 줄이지만 문제를 근본적으로 해결하지는 못합니다. 함축적 의미가 있는 복잡한 경우, 최고의 모델조차도 동기를 혼동하고 세부 사항을 꾸며냅니다. 이 위험은 신뢰할 수 있는 데이터(가격, 주소, 용량, 서비스 연락처)와 관련됩니다.

트라이아지-보이스 패턴

처리를 두 번의 LLM 패스로 나누고, 그 사이에 백엔드 게이트키퍼를 둡니다.

패스 1: 트라이아지. 스타일 없이 구조적 분석을 수행합니다. 모델이 신호를 JSON으로 추출합니다:

{
  "mood": "불안",
  "is_crisis": false,
  "crisis_type": null,
  "participants": [...],
  "motives": [...]
}

위기 사례:

{
  "mood": "적색 경고",
  "is_crisis": true,
  "crisis_type": "폭력"
}

백엔드 게이트. 결정론적 코드가 플래그를 확인합니다:

if (triage.IsCrisis) {
    var contacts = await db.GetVerifiedCrisisContacts(triage.CrisisType);
    prompt = crisisPromptTemplate.WithContacts(contacts);
}

데이터베이스에서 검증된 데이터가 삽입됩니다. 규칙에 따른 라우팅: 위기 → 특별 프롬프트.

패스 2: 보이스. 모델이 풍부한 입력을 받아 원하는 어조로 응답을 생성합니다. 사실을 분석하거나 지어내지 않습니다.

DeepSeek V3.2에서 테스트(수십 건의 위기 사례): 연락처 환각 현상 제로.

분리의 장점

• 책임 분리. 트라이아지는 구조(사실을 위한 토큰)에 집중합니다. 보이스는 스타일(공감을 위한 토큰)에 집중합니다. 두 차원 모두에서 품질이 향상됩니다(40개 평가 사례에서 검증됨).

• 캐싱. 분석은 한 번만 수행됩니다. 음성을 변경할 때(텔레그램 봇의 관점 변경) 보이스만 재실행됩니다. 지표: 첫 응답 30–45초(대비 50–90초), 후속 응답 15–20초.

• 안전성. 제어는 프롬프트가 아닌 코드에 있습니다. 모델이 플래그를 설정하고("언제"), 백엔드가 결정합니다("무엇"). 테스트 가능하고 예측 가능합니다.

적용 시나리오

이 패턴은 다음과 같은 LLM 제품에 적합합니다:

• 입력 분석 + 출력 생성.
• 신뢰할 수 있는 데이터(금융, 법률 참조, 의학).
• 엣지 케이스(위기, 예외).
• 재분석 없이 다중 관점.
• 분석과 출력 사이에 필요한 체크포인트.

원칙: 모델 분석 → 코드 결정 → 모델 구성.

리팩토링 신호: 프롬프트에 "[데이터]를 지어내지 마세요"가 포함된 경우.

핵심 포인트

• 아키텍처 전환: 작업 충돌을 제거하며, 한 번의 호출에서 게이트가 있는 두 번의 호출로.
• 성능 지표: 분석이 캐시되며, 보이스가 2–3배 빨라집니다.
• 안전성: 결정론적 백엔드가 사실을 삽입하며, 모델은 데이터베이스를 건드리지 않습니다.
• 확장성: 챗봇, 분석, 엣지 케이스가 있는 제품에 적용 가능.
• 검증됨: 40개 평가 + 수십 건의 위기 실행에서 환각 현상 없음.

단순 아키텍처의 위험

한 번의 호출 = 검증 없이 원자적 작업. 부족한 점:

• 사용자에게 도달하기 전 모델 결정 검증.
• 분석 캐시.
• 엣지 케이스 라우팅.
• 검증된 데이터 삽입.

중요한 부분에서 확률적 생성에 의존하는 것은 취약점입니다. 트라이아지-보이스는 제어를 추가합니다: +1 호출, +1 게이트 = 검증 가능한 파이프라인.

— Editorial Team