Orderly: 추측을 거부하는 AI WhatsApp 주문 처리기

작은 가게들은 종종 다음과 같이 WhatsApp을 통해 고객의 주문을 받습니다:

“쌀 2 kg, 기름 1 리터, 설탕 1 kg.”

하지만 실제 메시지는 훨씬 더 지저분할 수 있습니다. 즉, Telugu와 영어가 혼합되거나, 수정 사항이 있거나, 수량이 불분명하거나, 음성 메모일 수 있습니다.

어려운 부분은 단순히 메시지를 이해하는 것이 아닙니다.

진짜 문제는 AI가 전체 주문을 올바르게 이해했는지 여부를 아는 것입니다.

그래서 저는 Orderly를 만들었습니다.

제가 만든 것

Orderly는 작은 가게들을 위한 AI 지원 WhatsApp 주문 처리기입니다.

이것은 지저분한 텍스트와 음성 주문을 구조화된 주문으로 변환하고, 확인 전에 검사합니다.

핵심 원칙은 다음과 같습니다:

AI가 추출하고. 코드가 검증하며. 카탈로그가 결정한다. 증거가 불충분할 때 인간이 확인한다.

만약 주문이 명확하고 증거가 충분하다면, Orderly는 이를 CONFIRMED로 표시할 수 있습니다.

무언가가 불분명하거나, 누락되었거나, 불완전하거나, 검증하기에 안전하지 않은 경우, 추측하는 대신 NEEDS_REVIEW를 반환합니다.

데모

🎥 Orderly 데모 비디오 보기

데모는 Orderly가 고객 주문을 처리하고, 추출된 품목을 검증하며, 자동 확인이 되어서는 안 되는 경우를 처리하는 것을 보여줍니다.

비디오 스크립트

안녕하세요, 저는 작은 가게들을 위한 AI 기반 WhatsApp 주문 처리기인 Orderly입니다.

이는 Telugu-영어 메시지를 포함한 지저분한 텍스트와 음성 주문을 처리합니다.

핵심 원칙은 다음과 같습니다:

AI가 추출하고. 코드가 검증하며. 카탈로그가 결정한다. 증거가 불충분할 때 인간이 확인한다.

Orderly는 추출된 품목을 카탈로그와 대조하여 고객의 요청을 검증합니다.

증거가 충분하면 주문은 CONFIRMED될 수 있습니다.

무언가가 불분명하거나 불완전하면, Orderly는 추측하는 대신 NEEDS_REVIEW를 반환합니다.

목표는 간단합니다:

불완전한 주문을 절대 잘못 확인하지 않는 것.

Orderly를 사용해 보고, 코드를 탐색하고, 작은 가게들을 위한 안전한 AI 기반 주문 처리를 개선하기 위한 피드백이나 아이디어를 공유해 주세요.

코드

🔗 GitHub Repository

Orderly는 다음 기능을 갖춘 소규모 Python 애플리케이션으로 구축되었습니다:

• 웹 인터페이스 (Web interface)
• CLI (Command Line Interface)
• 결정론적 유효성 검사 (Deterministic validation)
• 카탈로그 확인 (Catalog checks)
• 자동화된 안전 테스트 (Automated safety tests)
• 결정론적 적대적 테스트를 위한 가짜 추출기 (Fake extractors for deterministic adversarial testing)

구축 과정 (How I Built It)

파이프라인은 다음과 같습니다:

고객 메시지 → 전사(transcription) → AI 추출 → 결정론적 유효성 검사 → 카탈로그 검증 → 확인/검토

음성 주문의 경우, 추출 전에 음성이 전사됩니다.

AI는 구조화된 주문 정보를 생성하지만, 이 애플리케이션은 AI 응답을 추출이 완료되었거나 정확하다는 증거로 취급하지 않습니다.

결정론적 코드가 추출된 정보와 고객 메시지 및 상점 카탈로그를 비교하여 확인합니다.

이러한 분리는 의도적입니다.

LLM(대규모 언어 모델)은 메시지를 오해하거나, 항목을 환각(hallucinate)시키거나, 단순히 무언가를 놓칠 수 있습니다.

따라서 시스템은 다음과 같이 설계되었습니다:

AI가 제안하고. 코드가 검증하며. 증거가 확인 허용 여부를 결정합니다.

안전 제일 (Safety First)

제가 중점을 둔 가장 큰 위험 요소 중 하나는 **고객-항목 누락(customer-item omission)**이었습니다.

예를 들어, 고객이 다음과 같이 말한다고 가정해 봅시다:

“쌀 2kg과 해바라기유 5리터”

하지만 AI가 추출한 것이 다음과 같을 경우:

“쌀 2kg”

일반적인 파이프라인은 불완전한 주문을 실수로 확인해 버릴 수 있습니다.

Orderly는 이를 추출된 목록이 완전하다고 가정하기보다는 검토 필요(NEEDS_REVIEW) 상황으로 처리하도록 설계되었습니다.

저는 특히 다음을 포함하는 적대적 사례를 테스트했습니다:

• 항목 하나가 누락된 여러 제품
• 항목 하나 이상이 누락된 세 가지 제품
• 중간 항목 누락 (Middle-item omission)
• 마지막 항목 누락 (Final-item omission)
• 다른 크기를 가진 동일한 제품
• 수정 사항 (Corrections)
• 혼합된 텔루구어 + 영어 주문
• “그리고 또한(And also)” 구성
• 관련 없는 텍스트가 포함된 긴 메시지

목표는 확인됨(CONFIRMED) 주문의 수를 최대화하는 것이 아닙니다.

목표는 불완전한 주문을 잘못 확인하는 것을 방지하는 것입니다.

오픈 혁신이 중요한 이유 (Why Open Innovation Matters)

이 프로젝트는 유용한 AI 시스템이 항상 폐쇄형 클라우드 서비스를 필요로 해서는 안 되기 때문에 오픈 소스 AI를 사용합니다.

오픈 모델과 오픈 소스 도구 덕분에 개발자들은 실험하고, 파이프라인을 검사하며, 모델을 로컬에서 실행하고, 특정 실제 문제들을 위한 시스템을 구축할 수 있습니다.

작은 상점(small-shop)의 사용 사례를 예로 들면, 로컬 및 오픈 툴링은 고객 데이터가 어떻게 처리되는지에 대해 더 많은 통제권을 제공할 수도 있습니다.

제가 얻은 중요한 교훈은, 오픈 AI는 무조건적으로 신뢰되기보다는 전통적인 결정론적(deterministic) 소프트웨어와 결합될 때 더 유용해진다는 것입니다.

에이전트 세션 (My Agent Session)

저는 프로젝트를 검사하고, 구현을 개선하며, 적대적 안전 테스트(adversarial safety tests)를 생성하고, 엣지 케이스(edge cases)를 조사하며, 애플리케이션을 검증하기 위해 AI 지원 개발을 사용했습니다.

개발 과정은 AI 추출이 정확해 보이지만 여전히 불완전할 수 있는 경우들을 찾는 데 중점을 두었습니다.

이는 더 강력한 설계 원칙으로 이어졌습니다:

성공적인 AI 응답을 고객의 전체 요청이 이해되었다는 증거로 절대 혼동하지 말 것.

테스트 (Testing)

자동화된 테스트 스위트에는 156개의 테스트가 포함되어 있으며, 155개는 통과했고, 0개는 실패했으며, 1개는 예상 실패(xfail)입니다.

Orderly automated test suite showing 156 tests collected, with 155 tests passed, 0 failed, and 1 expected failure (xfail). The terminal output demonstrates the project's deterministic safety, validation, and adversarial testing results.

예상 실패는 의도적입니다. 이는 추출기가 bellam과 같은 알 수 없는 제품을 완전히 누락하고, 고객 메시지가 완전성 검사기(completeness checker)가 누락을 감지할 만큼 충분한 인식 가능한 증거를 제공하지 않을 때 발생하는 알려진 한계를 문서화합니다.

이러한 한계는 숨겨지는 것이 아니라 문서화됩니다.

테스트들은 주로 **결정론적 안전 및 검증 테스트(deterministic safety and validation tests)**입니다. 이들은 추출이 불완전할 때 애플리케이션이 안전하게 실패하는지 테스트하기 위해 제어되거나 가짜 추출 동작을 사용합니다.

현재 환경에서는 Real-Gemma 유효성 검사가 수행되지 않았으므로, 이 테스트 결과는 실제 모델의 추출 품질 증거로 해석되어서는 안 됩니다.

현재 한계점 (Current Limitations)

Orderly는 프로토타입이며, 상용화된 자율 주문 처리 시스템이 아닙니다.

다음과 같은 경우 완벽하게 완전성을 보장하기 어렵습니다:

• 완전히 알려지지 않은 제품
• 모호한 언어
• 음성 인식 오류
• 특이한 구문(phrasing)
• 관련 없는 텍스트에 나타나는 제품 이름
• 해결하기 어려운 수정 사항
• 고객의 의도를 신뢰할 수 있게 식별할 수 없는 메시지

특히 중요한 한계점은, 완전성 검사기가 임의의 자연어에서 LLM이 가능한 모든 고객 의도를 추출했음을 수학적으로 증명할 수 없다는 것입니다.

따라서 가장 안전한 동작 방식은 충분한 증거가 없을 때마다 인간의 확인을 요청하는 것입니다.

이러한 문서화된 한계점 때문에, Orderly는 자동으로 이루어지는 자율 주문 처리에 있어 상용 환경에 안전하다고 간주되어서는 안 됩니다.

최종 생각 (Final Thoughts)

Orderly는 AI 주문 접수 아이디어로 시작했지만, 더 중요한 교훈은 **검증(verification)**이었습니다.

AI는 복잡한 인간의 언어를 이해하는 데 능합니다.

코드는 결정론적 규칙을 강제하는 데 더 뛰어납니다.

이 둘을 결합하면 어느 한쪽에만 의존하는 것보다 더 안전한 시스템을 만듭니다.

AI가 추출하고. 코드가 검증하며. 카탈로그가 결정합니다. 증거가 불충분할 때 인간이 확인합니다.

가장 중요한 설계 결정은 AI에게 CONFIRMED라고 말하게 하지 않은 것이었습니다.

그것은 시스템이 고객의 전체 요청이 표현되었는지 확립할 수 없을 때, 추측하는 것을 거부하도록 만드는 것이었습니다.

Orderly를 사용해보고 코드를 탐색하며, 소규모 상점을 위한 AI 기반 주문 처리를 더 안전하게 만들 방법에 대한 피드백이나 아이디어를 공유해주세요.

devchallenge #weekendchallenge #hf26challenge #opensource #ai #python