검증 실패(validation failure)는 숨겨야 할 예외 사항이 아닙니다. 그것은 당신의 시스템이 아직 어떻게 신뢰해야 할지 모르는 기록입니다.

LLM 추출 파이프라인(extraction pipelines)에서는 그 차이가 중요합니다. 형식이 잘못된 송장, 예상치 못한 OCR 레이아웃, 스키마(schema)를 위반하는 모델 응답, 그리고 의미론적으로 불가능한 값은 모두 동일한 검증 코드 라인에 도달할 수 있습니다. 만약 결과가 "재시도(retry)" 또는 "폐기(drop)"뿐이라면, 파이프라인은 동일한 실패를 반복하며 비용을 낭비하거나, 작업을 소리 없이 잃게 될 것입니다.

운영 환경(production)에서의 해답은 Dead-letter path입니다. 이는 실패한 기록들이 설명, 분류(triage), 그리고 안전하게 재실행(replay)될 수 있도록 충분한 증거와 함께 대기하는 내구성이 있는 장소입니다.

큐(queue) 자체는 쉬운 부분입니다. 어려운 부분은 이를 중심으로 실패 계약(failure contract)을 설계하는 것입니다.

검증은 라우팅이 시작되는 지점입니다

제약된 디코딩(Constrained decoding)과 사후 검증(post-hoc validation)은 서로 다른 문제를 해결합니다. 두 가지를 모두 사용하더라도 일부 기록은 실패해야 합니다. 실제 문서는 무질서하고, 스키마는 변경되며, OCR은 값을 손상시키고, 모델은 때때로 그럴듯한 헛소리(plausible nonsense)를 반환하기 때문입니다.

강력한 검증 경계(validation boundary)는 단순히 true 또는 false 이상의 것을 생성해야 합니다. 파이프라인의 나머지 부분이 조치를 취할 수 있도록 다음과 같은 이유를 방출해야 합니다:

• 어떤 스키마와 모델 버전이 사용되었는지
• 어떤 필드가 왜 실패했는지
• 페이로드(payload)가 형식이 잘못되었는지, 불완전한지, 또는 의미론적으로 유효하지 않은지
• 추출에 첨부된 신뢰도 신호(confidence signal)
• 재시도가 결과를 바꿀 가능성이 있는지

그 결과는 라우팅 결정(routing decision)이 됩니다.

신뢰도가 높고 유효한 기록은 앞으로 흘러갈 수 있습니다. 복구 가능한 전송 실패는 제한된 재시도(bounded retry)를 사용할 수 있습니다. 모호하거나 유효하지 않은 기록은 검토(review) 단계나 Dead-letter queue에 속해야 합니다. "모든 것을 신뢰하라"와 "모든 것을 검토하라"는 둘 다 좋지 않은 운영 모델이기 때문에, 신뢰도 기반 라우팅(Confidence-based routing)이 유용하게 쓰입니다.

Dead-letter 기록에는 페이로드뿐만 아니라 증거가 필요합니다

원래의 입력을 다른 큐(queue)에 넣는 것만으로는 충분하지 않습니다. 컨텍스트(context)가 없다면, 실패를 조사하는 팀은 흩어진 로그로부터 실행 과정을 재구성해야 하며, 만약 그 로그들이 여전히 존재한다면 말입니다.

저는 다음과 같은 내용을 포함하는 데드 레터 엔벨로프(dead-letter envelope)를 저장하겠습니다:

• 안정적인 레코드 ID(record ID) 및 멱등성 키(idempotency key)
• 민감도에 적절한 액세스 제어(access controls)가 적용된 불변(immutable) 소스 문서에 대한 참조
• 추출된 페이로드(payload). 단, 원시 모델 응답(raw model response)은 보존 정책(retention policy)이 허용하는 경우에만 포함
• 스키마(schema), 프롬프트(prompt), 모델(model), OCR, 그리고 파이프라인(pipeline) 버전
• 기계 판독 가능한(machine-readable) 형태의 유효성 검사 오류(validation errors)
• 신뢰도 점수(confidence score) 및 라우팅 임계값(routing threshold)
• 시도 횟수(attempt count) 및 타임스탬프(timestamps)
• 상관관계 ID(correlation ID) 또는 트레이스 ID(trace ID)
• 해당 레코드가 데드 레터 경로로 진입하게 된 명시적인 이유

이는 가능한 모든 필드를 수집하는 것이 목적이라기보다, 결정 과정을 보존하는 것에 가깝습니다. 6일 뒤에 엔지니어나 검토자가 다음과 같은 질문에 답할 수 있어야 합니다: 시스템이 무엇을 보았는가, 무엇을 생성했는가, 어떤 컨트랙트(contract)가 이를 거부했는가, 그리고 안전하게 재실행(replay)할 수 있는가?

데드 레터 큐(dead-letter queue)를 섀도 데이터베이스(shadow database)로 만들지 마십시오. 신뢰할 수 있는 원천(source of truth)이 이미 존재한다면 참조(reference)를 저장하고, 보존 및 삭제 규칙을 정의하며, 보안 제어가 더 약한 시스템으로 민감한 문서 내용을 복사하는 것을 피하십시오.

재시도하기 전에 실패를 분류하십시오

모든 실패가 다시 모델을 호출할 가치가 있는 것은 아닙니다.

저는 실패를 몇 가지 광범위한 클래스로 분류합니다:

1. 일시적인 인프라 장애 (Transient infrastructure failure). 타임아웃, 속도 제한 (Rate limit), 또는 사용 불가능한 의존성 (Dependency)은 나중에 성공할 수 있습니다. 지수 백오프 (Exponential backoff), 지터 (Jitter), 그리고 엄격한 예산 (Budget)을 적용하여 재시도하십시오.
2. 결정론적 계약 실패 (Deterministic contract failure). 동일한 페이로드 (Payload)가 매번 동일한 스키마 (Schema)를 위반하는 경우입니다. 입력, 프롬프트 (Prompt), 모델 (Model), 또는 스키마를 변경하지 않고 호출을 반복하는 것은 대개 실패를 재현하기 위해 비용을 지불하는 것과 같습니다.
3. 모호한 소스 데이터 (Ambiguous source data). 문서 자체에 충분한 근거가 없는 경우입니다. 모델에게 확실성을 지어내라고 요구하는 대신, 사람의 검토 (Human review) 단계로 라우팅하십시오.
4. 버전 불일치 또는 드리프트 (Version mismatch or drift). 새로운 문서 형식이나 스키마 버전이 기존의 가정을 깨뜨린 경우입니다. 영향을 받은 코호트 (Cohort)를 격리하고, 개별 레코드를 하나씩 수정하는 대신 시스템을 수정하십시오.
5. 정책 실패 (Policy failure). 민감도, 관할권, 또는 비즈니스 규칙으로 인해 해당 레코드를 자동으로 처리해서는 안 되는 경우입니다. 이는 영리한 재시도가 아니라 통제된 워크플로 (Workflow)가 필요합니다.

재시도 정책은 이러한 분류를 기반으로 해야 합니다. 재시도 예산 및 백프레셔 (Retry budgets and backpressure)가 중요한 이유는, 그렇지 않으면 제공업체의 장애가 하나의 실패한 요청을 값비싼 중복 요청의 폭풍으로 바꿀 수 있기 때문입니다.

재실행은 멱등성을 유지해야 합니다 (Replay must be idempotent)

데드 레터 큐 (Dead-letter queue)는 레코드가 그곳에서 안전하게 빠져나올 수 있을 때만 유용합니다.

위험한 재실행 구현 방식은 단순히 레코드를 처음으로 다시 보내는 것입니다. 만약 이전 시도에서 이미 부분적인 상태를 기록했거나, 이벤트를 방출했거나, 다운스트림 액션 (Downstream actions)을 트리거했다면, 재실행은 중복 송장, 중복 알림, 또는 일관성 없는 감사 추적 (Audit trails)을 생성할 수 있습니다.

안전한 재실행을 위해서는 멱등성 경계 (Idempotency boundary)가 필요합니다. 각 논리적 추출에 안정적인 키 (Stable key)를 부여하십시오. 다운스트림 쓰기 작업이 업서트 (Upsert) 방식이 되게 하거나, 알려진 처리 버전과 비교하도록 만드십시오. 어떤 단계가 완료되었는지 기록하십시오. 가능하다면 수정 사항의 영향을 받는 단계만 다시 실행하십시오.

또한 저는 재실행 시 그 근거가 되는 변경 사항을 명시하기를 원합니다:

• 새로운 스키마 버전 (new schema version)
• 교정된 OCR 출력 (corrected OCR output)
• 수정된 프롬프트 (prompt) 또는 제약된 출력 정의 (constrained-output definition)
• 새로운 모델 버전 (new model version)
• 검토자가 제공한 수정 사항 (reviewer-supplied correction)
• 복구된 상류 문서 (repaired upstream document)

"다시 시도하세요(Try again)"는 해결 전략이 아닙니다. "통화 파서(currency parser)를 수정한 후 스키마 v4에 대해 재실행(replay)하세요"가 해결 전략입니다.

인간의 검토는 재사용 가능한 신호를 생성해야 합니다

인간 참여형 (Human-in-the-loop) 시스템은 종종 더 조용한 방식으로 실패합니다. 즉, 검토 화면을 만들고 운영자에게 값을 수정하도록 요청한 뒤, 그 이유를 버려버리는 것입니다.

유용한 검토 워크플로 (workflow)는 다음과 같은 구조화된 결과물을 캡처합니다:

• 교정된 필드 값 (corrected field values)
• 수정에 대한 사유 코드 (reason code)
• 소스(source)가 모호했는지 또는 모델이 틀렸는지 여부
• 스키마 (schema) 또는 추출 로직 (extraction logic)을 변경해야 하는지 여부
• 감사 추적 (audit trail)을 위한 검토자 신원 및 타임스탬프

이러한 결과물은 단 하나의 레코드(record)보다 더 많은 것을 개선합니다. 이는 반복되는 문서 형식, 취약한 필드, 잘못된 임계값 (thresholds), 그리고 상류 (upstream) 단계에서 수정할 가치가 있는 실패 집단 (failure cohorts)을 드러냅니다. 또한 개인정보 보호 및 데이터 거버넌스 (data-governance) 규칙이 허용한다면, 큐레이션된 평가 예시 (evaluation examples)가 될 수도 있습니다.

목표는 인간을 영원히 루프 안에 가두어 두는 것이 아닙니다. 위험이 높은 곳에 인간의 주의력을 집중시키고, 반복되는 검토 작업을 엔지니어링 피드백으로 전환하는 것입니다.

데드 레터 큐 (Dead-letter queue)는 관측 가능성의 표면입니다

메트릭 (metrics)이 없는 DLQ는 놀라운 일들의 기록 보관소일 뿐입니다.

최소한 저는 다음 항목들을 추적할 것입니다:

• 처리된 레코드 대비 데드 레터 비율 (dead-letter rate)
• 사유, 문서 유형, 고객 또는 소스 집단, 스키마 버전, 모델 버전에 따른 실패 횟수
• 해결되지 않은 가장 오래된 레코드의 연령 (age)
• 실패 시점부터 검토 또는 해결까지 걸린 시간
• 재실행 (replay) 성공률
• 보존 기간 또는 검토 SLO를 초과하는 레코드
• 실패한 시도들로 인해 소비된 예상 토큰 (token) 또는 제공자 비용

단순한 횟수(count)가 아니라 비율(rate)을 주시하십시오. 트래픽이 증가하면 신뢰성이 향상되더라도 원시 횟수는 증가할 수 있습니다. 스키마, 프롬프트, OCR 또는 모델 변경 이후 발생하는 갑작스러운 실패율 (failure-rate) 급증은 훨씬 더 명확한 드리프트 (drift) 신호입니다.

이는 데드 레터 경로 (dead-letter path)를 더 넓은 관측 가능성 (observability) 이야기와 연결합니다. 트레이스 (traces)는 개별 실패를 설명하고, 집계 메트릭 (aggregate metrics)은 시스템의 신뢰도가 떨어지고 있는지 여부를 보여줍니다. 스키마 드리프트 (Schema drift)는 종종 필드 또는 문서 코호트 (cohort)별 검증 실패의 변화로 가장 먼저 나타납니다.

실질적인 제어 루프 (control loop)

제가 계속해서 되돌아오게 되는 아키텍처는 다음과 같습니다:

1. 스택이 지원하는 경우 생성 (generation)을 제한합니다.
2. 안전한 경우에만 결정론적 복구 (deterministic repair)를 적용합니다.
3. 타입이 지정된 결과 (typed result)를 검증하고 신뢰도 신호 (confidence signal)를 부착합니다.
4. 유효하고 신뢰도가 높은 레코드를 앞으로 전달합니다.
5. 예산 (budget) 범위 내에서 일시적인 실패 (transient failures)를 재시도합니다.
6. 모호하거나 유효하지 않은 레코드를 검토 단계 또는 내구성이 있는 데드 레터 경로 (dead-letter path)로 보냅니다.
7. 근본 원인을 수정하고, 멱등성 키 (idempotency key) 및 명시적인 처리 버전 (processing version)과 함께 재실행 (replay)합니다.
8. 실패 및 검토 결과를 스키마 (schemas), 평가 (evals), 프롬프트 (prompts) 및 파이프라인 모니터링 (pipeline monitoring)에 다시 피드백합니다.

이것은 confident-extract와 같은 도구 주변의 운영 계층입니다. 이 라이브러리는 PyPI에 게시되어 있으며 결정론적인 구조화된 추출 (structured extraction), 검증 및 신뢰도에 초점을 맞춥니다. 큐잉 (queueing), 검토, 보존 및 재실행 설계는 해당 경계 주변의 애플리케이션에 속합니다.

그러한 분리는 중요합니다. 유용한 오픈 소스 구성 요소는 전체 프로덕션 시스템이라고 주장하는 것이 아니라, 그 경계를 더 명확하게 만들어야 합니다.

실패 처리는 제품의 일부입니다

팀들은 종종 해피 패스 (happy path)를 먼저 설계하고, 실패한 레코드는 나중에 해결해야 할 운영 문제로 취급합니다.

LLM 시스템에서 실패 경로 (failure path)는 정상 경로의 일부입니다. 확률적 구성 요소 (probabilistic components), 지저분한 소스 데이터, 그리고 변화하는 계약 (contracts)은 일부 레코드가 다른 결정을 필요로 할 것임을 보장합니다. 시스템은 그 결정을 명시적이고, 내구성이 있으며, 관측 가능하고, 가역적 (reversible)으로 만듦으로써 신뢰를 얻습니다.

레코드를 버리지 마세요. 영원히 재시도하지 마세요. 증거를 보존하고, 위험에 따라 경로를 지정하며, 재실행 (replay)을 통제된 엔지니어링 작업으로 만드세요.

그것이 바로 "모델이 실패했다"라는 상황을 하나의 사고(incident)에서 워크플로(workflow)로 전환하는 방법입니다.

작성자: Hitarth Desai (hitarthbuilds), 신뢰할 수 있는 LLM 추출 및 MLOps 파이프라인을 구축하는 AI 시스템 엔지니어 (AI Systems Engineer). 그의 오픈 소스 confident-extract 패키지는 PyPI에서 확인할 수 있습니다. promptcrucible은 현재 활발히 개발 중입니다.

원문 게시: Hitarth Desai (hitarthbuilds), https://hitarthdesai.com/blog/dead-letter-queues-llm-extraction-pipelines/