AI 에이전트가 B2B 견적 회신 초안을 작성할 때의 휴먼-인-더-루프 승인 매트릭스 설계

만약 LLM 에이전트에게 수신된 B2B 견적 요청(RFQ)에 대한 회신 작성을 맡긴다면, 어려운 부분은 프롬프트가 아닙니다. 코드로 어떤 초안을 자체적으로 발송할지, 어떤 초안은 인간의 클릭이 필요한지, 그리고 에이전트가 절대 작성해서는 안 되는 초안은 무엇인지 결정하는 것입니다.

본 게시물에서는 저희가 소규모 수출 영업 데스크에서 사용하는 승인 매트릭스 패턴을 소개합니다. 이는 선언적 정책 파일(declarative policy file), 필드 레벨 분류기(field-level classifier), 그리고 모델과 아웃박스 사이에 위치하는 게이트 함수(gate function)로 구성됩니다. 예시는 Python과 YAML로 되어 있지만, 이 패턴은 특정 도구에 구애받지 않습니다.

우리가 설계하려는 실패 모드

RFQ 회신은 산문처럼 보이지만, 실제로는 일련의 약속들로 이루어져 있습니다: 단위 가격(unit price), 수량 등급(quantity tier), 리드 타임(lead time), 인코텀즈(Incoterm) (FOB, CIF, DDP...), 결제 조건(payment terms), 그리고 어쩌면 인증 주장 같은 것들이죠. '도움이 되도록' 요청받은 모델은 빈틈을 기꺼이 채울 것입니다. 구매자가 요청한 Incoterm과 일치시키거나, 리드 타임을 낮추어 제시하거나, 좋은 답변처럼 들리기 때문에

여기서 중요한 세부 사항 두 가지가 있습니다. 자동화되지 않은 모든 필드는 지정된 승인자가 있어 에스컬레이션이 공유된 공백에 떨어지지 않습니다. 그리고 source는 허용되는 값이 어디에서 올 수 있는지 선언합니다. 일치하는 소스 레코드가 없는 값은 비록 정확하더라도 임의로 만들어진 것으로 간주됩니다.

3단계: 모델이 구조를 출력하게 하고, 그 다음에 문장을 렌더링하기

모델에게 완성된 이메일을 요청하는 대신, JSON 객체를 요청하세요. 즉, 주장하고 싶은 필드와 그 주변의 문장입니다. 대부분의 현재 LLM API는 스키마 제약 출력을 지원하며, 이는 신뢰성을 높여줍니다.

{
  "fields": {
    "moq": {"value": "500 pcs", "source_ref": "catalogue:SKU-1182"},
...
}

이제 게이트는 정확히 무엇이 약속되고 있는지에 대해 추론할 수 있습니다.

4단계: 게이트

from dataclasses import dataclass, field

TIER_ORDER = {"auto": 0, "review": 1, "human_only": 2}
...

위의 샘플 초안을 사용하면, incoterm은 소스가 없고 CIF는 승인된 메뉴에 없으므로 결정은 escalate(상향 전달)이며 승인자는 ops가 됩니다. 그러면 에이전트는 단지 보류 회신만 보냅니다: 인지(acknowledge), MOQ를 확인하고, 배송 조건은 동료로부터 따를 것이라고 말합니다.

따라 할 만한 몇 가지 설계 선택 사항:

알 수 없는 필드는 닫힌 방식으로 실패합니다 (fail closed). 모델이 스키마가 알지 못하는 것을 주장하기 시작하면, 그것은 정책의 공백이지 통과(pass)를 의미하지 않습니다.
출처(provenance) 누락은 한 단계 상향 전달됩니다. 이 규칙 하나만으로도 대부분의 '자신감 있지만 지어낸' 값들을 포착할 수 있습니다.
하드 스톱(Hard stops)이 먼저 실행되며, 작성 모델에 의해서가 아니라 인바운드 메시지에 대한 별도의 분류기(classifier) 또는 단순 규칙에 의해 구동됩니다.

5단계: 결정 기록 및 올바른 측정하기

정책 버전, 초안, 승인자, 그리고 사람이 무언가를 변경했다면 편집 차이점(edit diff)을 포함하여 모든 게이트 결정을 저장합니다. 몇 주가 지나면 다음과 같은 유용한 질문에 답할 수 있습니다:

어떤 review 필드는 95% 이상 변경 없이 승인되나요? 그것들이 auto로 승격될 후보입니다.
어떤 필드가 가장 많이 수정되나요? 그것은 보통 모델이 아니라 원본 데이터(가격 책정집, 리드 타임)가 오래되었다는 것을 의미합니다.
적격한 RFQ(견적 요청)에 대한 중앙값 첫 회신 시간은 얼마인가요? 단순히 응답량을 아는 것만으로는 거의 아무것도 알 수 없습니다.

티어 간의 승격은 프롬프트 조정이 아니라 rfq_policy.yaml에 대한 검토된 변경이어야 합니다.

기성품 에이전트와의 연관성

마켓플레이스 판매자를 위한 패키징된 에이전트는 자체 승인 설정과 함께 출시되는 경우가 늘고 있습니다. 예를 들어, Alibaba.com의 Accio Work 에이전트는 스토어에 대한 초안 접수를 처리할 수 있으며, 저희는 팀이 인간 승인 단계를 포함하도록 Accio Work를 구성하는 방법을 작성했습니다. 그럼에도 불구하고, 정책이 도구 변경에도 살아남도록 위와 같은 명시적 매트릭스를 진실의 원천으로 유지하고 공급업체 설정을 여기에 매핑하는 것이 좋습니다.

만약 이것을 처음부터 구축한다면, 모델보다 데이터를 먼저 시작하세요. 짧은 RFQ 데스크를 위한 출시 전 체크리스트 (SKU 기본값, Incoterm 메뉴, 인증서 등록부, 지정된 승인자)는 어떤 프롬프트 엔지니어링보다도 더 많은 사고를 예방해 줄 것입니다.

요약

메시지가 아닌 필드를 분류하세요: auto, review, 또는 human_only.
매트릭스를 이름이 지정된 승인자와 필수 소스가 포함된 버전 관리형 설정 파일에 유지하세요.
모델이 구조화된 필드를 내보내도록 하고, 산문(prose)을 렌더링하기 전에 이를 게이트 처리하세요.
알 수 없는 필드와 누락된 출처(provenance)에 대해서는 실패 시 폐쇄(Fail closed) 원칙을 적용하세요.
로그된 승인 데이터를 기반으로 코드를 통해 필드를 auto로 승격시키세요.

워크플로우에서 에이전트 출력을 어떻게 게이트 처리하고 계신가요? 다른 분들이 필드 수준의 정책을 사용하시는지 아니면 더 광범위한 무언가를 사용하는지 궁금합니다.