음성 AI 주문에서 인간은 무엇을 확인해야 하는가?

합성 음성 주문 예시에서, 반복된 음성 토큰이 버거 3개로 변환됩니다. 시스템은 수량을 1개로 변경하라는 그럴듯한 수정안을 제시합니다. 제품 팀에 있어 어려운 질문은 그 제안과 주문 제출 승인 사이에 무슨 일이 일어나는가입니다. 도움이 되어 보이는 대체안도 고객이 무엇을 원했는지를 입증하지는 못했습니다.

공개 고지: 아래 예시는 시뮬레이션된 주방 디스플레이 앞에서 구조화된 공급업체 출력을 검증하는 Veriprajna의 Drive-Thru Order Firewall 내의 합성 주문입니다. 실제 오디오를 인식하거나 레스토랑의 POS 시스템으로 주문을 전송하지는 않습니다.

저는 사람의 확인이 특정한 불확실성을 해결하기를 원합니다. 이를 위해서는 세 가지 판단을 분리해야 합니다: 고객이 의도한 것, 해당 주문이 레스토랑 정책상 허용되는지 여부, 그리고 제안된 정확한 주문이 검사를 충족하는지 여부입니다. 이러한 판단들을 단 하나의 승인 버튼으로 결합하면 승인이 무엇을 의미하는지 알기 어렵게 됩니다.

수정은 의도에 관한 가설이다

반복 토큰 픽스처에는 불완전한 전사본, 3개의 동일한 원시 토큰, 버거 3개의 수량이 포함되어 있습니다. 제공된 신뢰도 점수는 0.71로 설정된 검토 기준값인 0.85 미만입니다. 따라서 반복 및 낮은 신뢰도 규칙이 주문을 HOLD 상태로 둡니다. 반복 규칙은 버거 1개를 제안합니다.

1개는 운영자에게 제시할 합리적인 후보입니다. 하지만 의도된 수량의 증거는 아닙니다. 반복된 토큰이 구조화된 출력을 설명할 수는 있지만, 반복을 감지하는 규칙이 고객에게 그 의도를 물어볼 수는 없습니다. 3개를 1개로 자동 대체하는 것은 의문스러운 해석을 미확인된 해석과 맞바꾸는 셈이 됩니다.

주문을 거부하는 것은 다른 비용을 수반합니다. 명확화가 필요한 해석을 마치 수용 가능한 주문을 복구할 수 없는 것처럼 취급하기 때문입니다. 저는 이 시점에서 보류(hold)를 선호하는데, 원래의 증거를 보존하고 의도된 수량을 열어두기 때문입니다. 프로덕션 설계에서 확인은 운영자에게 시스템의 일반적인 신뢰도를 지지하도록 요구하기보다는 수량 자체를 물어야 합니다.

그것은 설계상의 입장이며, 이 앱에서 완성된 워크플로가 아닙니다. 데모의 Approve Correction 및 Escalate 버튼은 레이블을 변경하고 자체적으로 비활성화됩니다. 다시 제출하거나, 해제하거나, 사람의 작업을 기록하거나, 영수증을 변경하지 않습니다. 프로덕션 팀은 답변에 실질적인 효력을 부여하는 대화와 상태 변경을 여전히 구축해야 합니다.

특이한 요청도 정확히 이해되었을 수 있다

해석은 일시 중지하는 하나의 이유일 뿐입니다. 또 다른 합성 픽스처에는 제공된 신뢰도 점수 0.97과 고객 메뉴 가격이 0원인 물 18,000잔이 포함되어 있습니다. 수량이 설정된 물 상한선인 8잔을 초과하므로 게이트가 이를 보류합니다. 높은 입력 점수도 0원의 가격도 그 수량이 진행될 수 있는지 여부에 답하지 못합니다. 그 점수는 픽스처의 입력값일 뿐, 승인에 대한 보정된 확률이 아닙니다.

극단적인 수량은 이러한 구분을 쉽게 확인할 수 있게 합니다. 더 어려운 제품 결정은 고객이 실제로 원하는 특이한 수량입니다. 레스토랑의 일반적인 자동 제한을 초과하는 가상의 단체 주문을 생각해 보십시오. 고객이 숫자를 확인하면 허가는 해결되지 않은 채 해석은 정착될 수 있습니다. 이를 통상적인 상한선으로 줄이는 것은 요청을 변경하는 것입니다. 완전히 거부하는 것은 정당한 수요를 버릴 수 있습니다.

저는 정책이 예외를 허용할 때 검토를 트리거하기 위해 예외 기준값을 사용하는 것을 선호합니다. 그러면 운영자는 레스토랑이 별도로 승인된 경로를 통해 확인된 주문을 수락할 수 있는지 여부를 결정해야 합니다. 자동 제출을 제한하도록 설계된 기준값이 고객의 의도를 다시 작성하는 규칙으로 은근슬쩍 바뀌어서는 안 됩니다.

여기에는 주의의 비용이 듭니다. 더 느슨한 자동 기준값은 더 특이한 주문을 통과시키고, 더 엄격한 기준값은 더 많은 검토 작업을 만듭니다. 데모는 레스토랑을 위해 그 균형을 선택할 수 없습니다. 상한선은 초기 합성 주문 기록에서 파생되었으며, 분포는 그 기록에 나타난 것을 설명합니다. 실제 매장의 수용 능력이나 합법적인 단체 주문이 얼마나 자주 발생할지는 확립하지 않습니다. 그러한 정책을 채택하기 전에 팀은 허용 가능한 예외와 이를 확인하는 실질적인 부담에 대한 증거가 필요합니다.

확인은 바로 다음 주문에 정확히 적용되어야 한다

확인된 수정조차 무효 상태로 남을 수 있습니다. 대량 주문 픽스처는 감자튀김 40개와 탄산음료 40개로 시작합니다. 수량 규칙은 감자튀김을 4개로 줄일 것을 제안하지만 탄산음료 40개는 그대로 둡니다. 탄산음료 상한선은 6개입니다. 따라서 감자튀김 4개가 올바른 대체물이라는 데 동의하더라도 제안된 주문에는 또 다른 수량 위반이 남게 됩니다.

이것이 제가 확인과 검증을 분리하여 유지하는 이유입니다. 고객 확인은 의도를 다룹니다. 권한을 가진 운영자의 예외 결정은 정책을 다룹니다. 제안된 전체 주문을 검사하는 것은 다음 거래가 해당 규칙을 충족하는지 여부를 다룹니다. 이러한 답변 중 어느 것도 다른 답변에서 안전하게 추론할 수 없습니다.

프로덕션 워크플로의 경우, 제출 전에 확인된 제안이 검증을 다시 통과하도록 요구할 것입니다. 운영자가 정책을 재정의할 수 있는 경우, 해당 권한은 명시적이어야 하며 수락되는 특정 규칙 및 주문에 첨부되어야 합니다. 일반적인 승인이 관련 없는 실패를 지워서는 안 됩니다. 이는 향후 구현을 위한 요구 사항이며 현재의 수정 컨트롤이 시연하는 기능이 아닙니다.

조언은 권한을 부여하지 않고도 도움이 될 수 있다

설명 모델 메모는 유용하지만 더 좁은 역할을 가집니다: 보류 이유를 더 읽기 쉽게 만들 수 있습니다. 동봉된 창립자 녹화에서 해당 메모는 캐시된 실제 자문 응답을 사용합니다. 재생할 때마다 새로운 추론을 수행하는 것은 아닙니다. 엔진은 먼저 결정론적 규칙을 사용하여 결정하며, 이후의 자문 텍스트는 결정을 변경할 수 없습니다. 자문 호출은 처리 내에서 동기식으로 이루어지므로, 이러한 권한 분리가 모델 작업으로 인해 요청 지연 시간이 추가되지 않는다는 것을 증명하지는 않습니다.

이러한 주문 검증 상세 분석은 이 경계와 합성 예시를 보여줍니다. 이는 검토 가능한 설계 논거를 뒷받침할 뿐, 초기 설정된 정책이나 미완성된 운영자 워크플로가 배포 준비를 마쳤다는 증거는 아닙니다.

여기 주문 검토 예시에 대한 창립자 녹화가 있습니다.

제게 있어 결정적인 제품 검토는 제안된 주문을 허용된 다음 조치까지 완전히 추적하는 것입니다. 누가 그 의미를 확인했는가? 누가 예외를 수락할 수 있는가? 무엇이 전체 결과를 검사했는가? 그 답변들이 정확히 동일한 주문을 가리킬 때까지 안심을 주는 수정과 승인 레이블은 거래를 미완성 상태로 남겨둡니다.