가맹점 등록 증빙 자료 검토를 위한 로컬 Gemma 4 검토 도구 구축

이것은 Gemma 4 Challenge: Build with Gemma 4에 대한 제출물입니다.

내가 구축한 것
지루하지만 실제적인 워크플로우, 즉 가맹점이나 공급업체가 제공한 이름 뒤에 출처가 확인된 공개 증빙 자료가 있는지 확인하기 위한 아주 작은 로컬 우선 (local-first) 검토 도구를 구축했습니다. 이 스크립트는 공개된 사업자 등록 기록과 선택적인 WHOIS 데이터를 검색한 다음, 로컬에서 실행되는 Gemma 4 모델에게 원시 증빙 자료를 검토자 친화적인 요약본으로 변환하도록 요청합니다.

요약본에는 다음 내용이 포함됩니다:

• 가장 강력한 공식 출처 일치 항목 (strongest official-source matches)
• 과도하게 신뢰해서는 안 되는 모호하거나 이름이 유사한 일치 항목 (fuzzy or name-similar matches)
• 상태, 주소, 관할 구역 또는 소유권 증빙과 같이 누락된 필드
• 제안된 다음 검증 단계
• 출처 URL이 포함된 간결한 증빙 테이블

핵심은 LLM이 비즈니스의 적법성을 결정하게 만드는 것이 아닙니다. 그것은 부주의한 방식입니다. 핵심은 모델이 받은 정확한 JSON 데이터에 근거(grounded)를 두면서, 인간 검토자에게 지저분한 공개 기록에 대한 깔끔한 1차 검토를 제공하는 것입니다. 이것은 제가 가맹점 인수 (merchant underwriting) 및 KYB (Know Your Business) 데이터를 다룰 때 원했던 종류의 도구입니다. 업무의 상당 부분은 화려한 AI 추론이 아닙니다. 거의 일치하는 여러 엔티티 이름을 보고 "이 중 어떤 것이 실제 일치 항목이고, 어떤 것이 노이즈이며, 어떤 증빙이 여전히 누락되었는가?"를 묻는 과정입니다.

데모 코드와 샘플 출력은 여기에서 확인할 수 있습니다: https://gist.github.com/avabuildsdata/ac8054a90011563c665545844e194561

Ollama를 사용하여 로컬에서 실행하기:
ollama pull gemma4:e4b
python3 merchant_evidence_brief.py "OpenAI" --states NJ,NY,TX,CA --domain openai.com

모델이 확인하기 전에 정확한 증빙 자료를 직접 검사할 수도 있습니다:
python3 merchant_evidence_brief.py "OpenAI" --states NJ,NY,TX,CA --domain openai.com --raw

내 실행 결과의 단축된 샘플:

검토자 요약 (Reviewer Summary)

공개 기록 검색 결과 뉴저지, 텍사스, 뉴욕 전역에서 "OpenAI"에 대한 여러 잠재적 일치 항목이 발견되었습니다. 가장 강력한 일치 항목은 뉴저지에 있는 두 엔티티인 "OPENAI OPCO, LLC"와 "OPENAI, L.L.C."입니다. WHOIS 데이터는 openai.com 도메인이 MarkMonitor, Inc.를 통해 등록되었으며 2029년에 만료될 예정임을 확인해 줍니다.

TX(텍사스)와 NY(뉴욕)의 나머지 결과들은 퍼지 매칭 (Fuzzy matches)이며, 그중 여러 건은 비활성 (Inactive) 상태로 나열되어 있습니다. ### 주의 사항 / 누락된 증거 - 해당 증거는 어떤 엔티티 (Entity)의 소유권이나 현재 운영 상태를 증명하지 못합니다. - 나열된 대부분의 엔티티에 대해 구체적인 거리 주소가 누락되어 있습니다. - WHOIS 데이터는 등록 대행자 (Registrar) 및 등록 날짜만 보여줄 뿐, 도메인의 최종 소유자를 확인해주지는 않습니다. 마지막 문장이 중요합니다. 제가 작성한 첫 번째 프롬프트 (Prompt) 버전은 충분히 엄격하지 않았고, 모델이 WHOIS 등록 정보를 실제보다 더 강력한 증거로 취급하기 시작했습니다. 저는 지침을 강화하여 등록 대행자 및 도메인 날짜는 회사 소유권의 증거가 아니라고 명시적으로 말하도록 했습니다. 두 번째 출력 결과는 훨씬 더 안전했습니다. 코드 전체 데모는 단일 Python 파일로 구성되어 있습니다. 다음을 사용합니다: 공식 출처 증거를 위한 AutoScrape의 공개 인증 없는 (no-auth) API, HTTP 및 JSON 처리를 위한 Python 표준 라이브러리, Ollama의 로컬 /api/generate 엔드포인트, 기본값으로 gemma4:e4b를 사용하며 더 강력하지만 느린 옵션으로 gemma4:31b를 사용합니다. 핵심 프롬프트는 의도적으로 보수적입니다: 아래의 JSON 증거만을 사용하십시오. 증거가 말하는 범위를 넘어 법적 상태, 정당성, 사기 또는 소유권을 추론하지 마십시오. WHOIS 등록 대행자/도메인 날짜는 회사 소유권의 증거가 아닙니다. 필드가 누락된 경우 누락되었다고 말하십시오. 가능한 매칭이 여러 개인 경우, 정확해 보이는 매칭과 퍼지/이름 유사 매칭을 분리하십시오. 그 제약 조건이 바로 결과물입니다. 이러한 워크플로우 (Workflow)에서는 근거 없는 자신감 있는 주장이 답변이 누락된 것보다 더 나쁩니다. Gemma 4 활용 방법: 저는 구조화된 공개 증거 위에서 로컬 추론 및 작성 레이어 (Layer)로 Gemma 4를 사용했습니다.

저는 기본 모델로 gemma4:e4b를 선택했습니다. 이는 도전 과제의 제약 조건 사이에서 유용한 중간 지점을 충족하기 때문입니다. 이 모델은 Ollama를 통해 제 로컬 머신에서 실행되며, 대화형 검토 루프(Reviewer loop)를 돌리기에 충분히 빠르고, 여러 등록 결과와 WHOIS 증거를 포함할 수 있는 충분한 컨텍스트(Context)를 보유하고 있으며, 호스팅된 모델이나 제3자 LLM API 없이도 구조화된 마크다운(Markdown)을 생성할 수 있습니다. 실제 운영 버전(Production version)을 만든다면 아마도 다음과 같이 모델 선택권을 제공할 것입니다: 빠른 1차 검토를 위한 gemma4:e4b, 증거가 모호할 때 더 느리지만 고품질의 검토를 위한 gemma4:31b, 그리고 원본 JSON만을 원하는 감사인을 위한 --raw (모델 미사용) 모드입니다. 여기서 Gemma 4가 가능하게 한 것은 마법 같은 분류가 아니었습니다. 그것은 까다로운 공식 출처 기록들에 대한 로컬의, 프라이빗한, 반복 가능한 합성(Synthesis)이었습니다. 이는 컴플라이언스(Compliance) 관련 업무에 매우 적합한데, 민감한 부분은 종종 가맹점 목록 그 자체이기 때문입니다. 모델을 로컬에 유지한다는 것은 해당 목록을 호스팅된 모델 제공업체로 전송하지 않고도 워크플로우를 테스트할 수 있음을 의미합니다.

배운 점
주요 교훈은 모델의 유용성이 증거의 경계(Evidence boundary)에 달려 있다는 것이었습니다. 만약 제가 "이 가맹점이 합법적인가요?"라고 묻는다면, 모델은 추측만 할 수 있습니다. 하지만 "오직 이 기록들만을 바탕으로 했을 때, 어떤 이름이 정확해 보이고, 어떤 것이 퍼지(Fuzzy) 매칭이며, 무엇이 누락되었나요?"라고 묻는다면 모델은 훨씬 더 유용해집니다. 또한 로컬 모델은 공개 데이터와 관련된 많은 지루한 작업들, 즉 이름의 중복 제거(Deduplicating), 검토자 노트 작성, 누락된 증거를 명확히 하는 작업 등에 충분히 훌륭하다는 것을 배웠습니다. 모델이 반드시 기록 시스템(System of record) 그 자체가 될 필요는 없습니다. 모델은 기록 시스템을 더 읽기 쉽게 만들어 줄 필요가 있습니다.

다음에 추가하고 싶은 것
만약 하루의 시간이 더 주어진다면, CSV 가맹점 목록을 위한 배치 모드(Batch mode)와 요약본이 케이스 관리(Case-management) 또는 언더라이팅(Underwriting) 대기열에 바로 연결될 수 있도록 더 엄격한 JSON 출력 옵션을 추가할 것입니다. 가장 중요한 향후 기능은 평가(Evaluation)가 될 것입니다. 즉, 정확함(Exact), 퍼지(Fuzzy), 불일치(No-match)로 알려진 소규모 사례 세트를 구축하여, 증거가 더 지저분해지더라도 프롬프트/모델 조합이 보수적인 태도를 유지하는지 측정할 수 있도록 할 것입니다.