생성 후 결정하기: Cloudflare Clef를 의사결정 레이어로 사용하기

대부분의 LLM 파이프라인은 하나의 모델에게 두 가지 작업을 시키는 경향이 있습니다. 즉, 답변을 작성하고 그것이 좋은지 판단하는 것입니다. 이들은 서로 다른 문제입니다. 작문(Writing)은 개방형(open-ended)입니다. 반면, 판단(Judging)은 유한한 선택지(bounded choice)입니다. 지원되는지 여부, 안전한지 여부, 출시 가능한지 여부 등이 있습니다.

Clef는 Cloudflare가 이 두 번째 작업에 대해 만든 모델입니다. Clef에게 산문(prose)을 요청하는 것이 아닙니다. 대신 상태(state) (텍스트, JSON, 이미지)와 **타입화된 질문(typed questions)**의 스키마를 제공하면, 모든 허용 가능한 옵션에 대한 확률을 반환합니다. 이는 구축 방식을 변화시킵니다. 의사결정이 파싱해야 하는 문장이 아니라 코드가 확인할 수 있는 구조화된 객체가 되는 것입니다.

저는 실제 파이프라인에서 이것이 어떻게 작동하는지 확인하기 위해 작은 개념 증명(proof of concept)인 Evidence Lab을 만들었습니다: RAG 답변이 실제로 출처에 의해 뒷받침되는지 여부를 확인합니다.

문제점: 올바른 인용, 잘못된 의미

정책상 _회원(members)_은 개봉하지 않은(unopened) 품목을 반품할 수 있다고 가정해 봅시다. 하지만 '모든 고객(all customers)'이 '어떤(any)' 품목이든 반품할 수라는 답변은 정확한 문서를 인용했더라도 여전히 틀릴 수 있습니다. 인용 검사는 통과합니다. 하지만 의미는 그렇지 않습니다.

이를 문자열 매칭만으로는 잡아낼 수 없으며, 같은 LLM에게

무엇이 빠져 있는지 주목하세요. 출력 파싱(output parsing)도 없고, 'JSON 형식으로만 응답' 지시어도 없으며, 모델이 대화로 되돌아올 때 재시도하는 것도 없습니다. 스키마가 바로 계약입니다.

적용하기: RAG를 위한 검증 게이트

Evidence Lab에서는 생성기(generator)가 답변을 작성하고, Clef가 이를 보여줄 수 있을지 결정합니다. 최종 호출은 모델이 아니라 애플리케이션 코드에서 이루어집니다.

다이어그램은 하나의 질문이 파이프라인을 통과하는 과정을 보여줍니다. **코퍼스(corpus)**는 검색되는 문서들의 모음입니다. **증거 묶음(evidence pack)**은 이 질문을 위해 검색된 발췌문들로 구성됩니다. 이 묶음을 고정하면, 답변은 작성될 때 사용된 것과 동일한 자료를 기반으로 확인되고 수정됩니다.

flowchart TD
  Question[질문] --> Retrieve[증거 검색 및 고정]
  Retrieve --> Draft[인용된 답변 블록 생성]
...

각 블록이 하는 역할은 다음과 같습니다:

1. 질문(Question): 파이프라인은 사용자의 질문과 선택된 코퍼스를 받습니다.

2. 증거 검색 및 고정(Retrieve and freeze evidence): 검색된 발췌문들은 ID와 버전으로 고정됩니다. 생성, 검증, 수정 과정 모두 이 동일한 묶음을 사용합니다. 그렇지 않으면 생성기가 본 적 없는 자료를 기반으로 검증하게 됩니다.

3. 인용된 답변 블록 생성(Generate cited answer blocks): LLM은 인용 ID가 포함된 구조화된 블록들을 작성합니다. 하나의 블록에는 여러 개의 사실적 주장(factual claims)이 포함될 수 있습니다. 이것이 개방형 '생성' 절반입니다.

4. 구조 및 인용 확인(Check structure and citations): 일반 코드가 스키마, 인용 ID, 그리고 따온 텍스트를 검증합니다. 유효하지 않은 초안은 Clef 호출을 사용하기 전에 여기서 중단됩니다.

5. Clef: 지원 여부 및 전역 기준 확인(Clef: check support and global criteria): 이것이 '결정' 절반입니다. 질문, 정확한 초안, 그리고 고정된 증거가 state로 Clef에 전달되며, 각 블록은 네 가지 옵션을 가진 하나의 choice 질문이 됩니다:

   questions[`block.${i}`] = {
     type:

-   답변이 작업 범위 내에 머무르는가?
-   내부적으로 일관성이 있는가?
-   검색된 발췌문 중 답변이 인용한 것뿐만 아니라, 그렇지 않은 발췌문을 포함하여 모순되는 부분이 있는가?

마지막 확인은 불편한 증거를 조용히 무시한 답변을 포착합니다. Clef는 호출당 최대 64개의 질문을 허용하므로, 전체 판결이 한 번의 왕복으로 돌아옵니다.

1. **전체 판결 유효성 검사:** 판결을 맹신해서는 안 됩니다. 코드는 예상되는 모든 질문에 정확히 한 번 답변해야 하며, 이후 레이블, 확률, 답변 및 증거의 해시, 그리고 라운드 ID를 확인합니다. 통과하려면 모든 블록이 `지원됨(supported)`이어야 하고 모든 글로벌 검사가 통과해야 합니다. 확률은 아직 보정되지 않았으므로, 이들에 대한 임계값 설정은 먼저 평가가 필요합니다.
    
2. **한 번의 수정:** 거부된 초안은 실패한 검사 ID와 동일한 증거를 사용하여 정확히 한 번 재작성됩니다. 새 초안은 구조적 검사와 Clef를 다시 거칩니다.
    
3. **기권(Abstain):** 수정한 내용마저도 검증에 실패하면, 시스템은 기권을 반환합니다. 초안은 절대 게시되지 않습니다.
    
4. **기술적 오류:** 유효하지 않은 데이터, 누락된 검사, 해시 불일치, 시간 초과 또는 예산 소진 중 어느 것이든 발생하면 실행이 중단됩니다. 잘못 구성된 판결은 통과가 아닌 실패로 처리됩니다. 원격 호출은 전송 전에 사용량을 예약하며, 전송 재시도는 별도의 제한을 가집니다.
    
5. **게시 게이트:** 검사를 통과하는 것은 필요조건이지만 충분조건은 아닙니다. 실제 배포(live release)는 현재 구성 및 구현과 일치하는 적격 정책(qualified policy)도 요구합니다. '적격'하다는 것은 배포 설정이 검토된 평가 증거와 연결되어 있음을 의미합니다.
    
6. **배포 응답:** 게이트를 통과하면, 승인된 블록과 그 인용문들이 일반 답변 필드에 게시됩니다.
    
7. **운영자 추적만(Operator trace only):** 섀도우 모드(shadow mode)이거나 적격하지 않은 라이브 정책의 경우, 초안과 판결은 검사를 위해 보관됩니다. 사용자는 아무런 답변을 볼 수 없습니다.

## 일반적인 패턴

RAG 세부 사항을 제거하면 설계는 재사용 가능합니다:

## 일반적인 패턴

RAG의 세부 사항을 제거하면 설계는 재사용 가능합니다:

1.  **LLM이 생성함** (개방형, 창의적, 추론하기에 비용이 많이 듦).
2.  **Clef가 결정함** (제한된 레이블, 확률, 단일 호출).
3.  **사용자 코드가 강제함** (유효성 검사, 임계값, 재시도, 출시 정책).

RAG 외에 제가 생각하기에 적용될 수 있는 영역 (아이디어이며 테스트한 것은 아님):

-   **지원 티어 분류(Support triage):** 하나의 호출로 라우팅하고 긴급도를 표시하며 심각도를 점수화함 (Cloudflare 자체 예시).
-   **에이전트 가드레일(Agent guardrails):** 에이전트가 도구를 실행하기 전에, 해당 행동이 사용자 요청과 일치하는지 그리고 되돌릴 수 있는지 질문함.
-   **콘텐츠 조정(Content moderation):** 모호한