웹사이트에 채팅 인터페이스를 추가하는 것은 쉽습니다. 하지만 회사의 특정 질문에 신뢰할 수 있게 답변하도록 만드는 것이 실제 엔지니어링 및 콘텐츠 문제입니다.

지원 어시스턴트(support assistant)에게는 유능한 언어 모델(language model) 그 이상의 것이 필요합니다. 통제된 소스 세트, 검색 워크플로우(retrieval workflow), 테스트 프로세스, 그리고 가용 지식이 불충분할 때를 대비한 명확한 폴백(fallback)이 필요합니다.

이 기사는 중소규모 제품을 위한 실무적인 '웹사이트-to-답변' 워크플로우를 설명합니다. 이는 Oscar Chat을 구축하며 얻은 교훈을 바탕으로 하지만, 그 원칙은 검색 기반(retrieval-based)의 모든 고객 지원 어시스턴트에 적용될 수 있습니다.

소스 소유권(source ownership)부터 시작하기

무언가를 크롤링(crawling)하기 전에, 비즈니스에서 어떤 페이지를 권위 있는 것으로 간주할지 정의해야 합니다.
공개된 웹사이트에는 종종 동일한 정보의 여러 버전이 포함되어 있습니다. 오래된 캠페인 랜딩 페이지, 현재의 가격 페이지, 보관된 문서, 번역된 페이지, 그리고 더 이상 제공되지 않는 기능을 설명하는 블로그 게시물이 있을 수 있습니다.
크롤러는 이 모든 것을 수집할 수 있지만, 수집이 곧 진실은 아닙니다.
유용한 소스 정책은 세 가지 질문에 답해야 합니다: 어떤 경로가 허용되는가, 어떤 경로가 제외되어야 하는가, 그리고 두 소스가 충돌할 때 어떤 페이지가 우선하는가.
첫 번째 구현을 위해서는 안정적인 페이지가 가장 안전한 소스 세트입니다: 문서(documentation), 제품 페이지, FAQ, 배송 및 반품 정책, 서비스 설명, 그리고 현재 가격 설명 등이 이에 해당합니다.
추출(extraction)과 인덱싱(indexing)을 분리하기

크롤러(crawler)는 페이지를 수집합니다. 지식 파이프라인(knowledge pipeline)은 해당 페이지들을 사용 가능한 근거(evidence)로 변환합니다.

추출(extraction) 레이어는 반복되는 내비게이션, 쿠키 배너, 관련 없는 푸터(footer) 콘텐츠, 그리고 노이즈를 유발하는 기타 텍스트를 제거해야 합니다. 또한 페이지 제목, 헤딩(heading), 의미 있는 단락 경계, 그리고 소스 URL은 보존해야 합니다.

그 후 인덱싱(indexing) 레이어는 정제된 콘텐츠를 검색 가능한 단위로 나눌 수 있습니다. 정확한 청킹(chunking) 전략은 페이지 구조에 따라 다르지만, 유용한 청크(chunk)라면 독립적으로 검색되었을 때도 의미를 파악할 수 있을 만큼 충분한 문맥(context)을 유지해야 합니다.

예를 들어, “그것은 30일 동안 이용 가능합니다”라는 문장은 “그것”이 무엇을 의미하는지 설명하는 헤딩이나 앞선 설명이 없다면 유용하지 않습니다.

메타데이터(metadata) 또한 똑같이 중요합니다. 최소한 페이지 URL, 페이지 제목, 섹션 헤딩, 언어, 그리고 크롤링 시간(crawl time)은 유지해야 합니다. 이러한 필드들은 디버깅(debugging), 필터링(filtering), 그리고 향후 업데이트(refresh) 시에 도움이 됩니다.

검색(retrieval)에는 불확실성 정책(uncertainty policy)이 필요합니다

흔히 발생하는 실패 사례는 어시스턴트(assistant)가 그럴듯한 텍스트를 생성할 수 있을 때마다 답변하도록 허용하는 것입니다.
고객 지원(customer support)의 경우, ‘그럴듯함’은 기준이 될 수 없습니다. 답변은 반드시 검색된 소스(source)에 의해 뒷받침되어야 합니다.
시스템에는 불확실성 정책이 필요합니다. 만약 가용한 근거가 약하거나, 상충되거나, 누락되었다면, 어시스턴트는 답변을 확인할 수 없다고 말하고 상담원 연결(human handoff)이나 문의 양식을 제공해야 합니다.
이러한 동작은 특히 가격, 환불, 법적 약관, 의료 정보, 금융 서비스, 그리고 주문 관련 질문에서 매우 중요합니다.
가장 좋은 폴백(fallback)은 일반적인 에러 메시지가 아닙니다. 방문자에게 다음에 무엇을 할 수 있는지 알려주어야 합니다: 연락처 남기기, 라이브 채팅 시작하기, WhatsApp 열기, 또는 적절한 팀에 질문 보내기 등입니다.
실제 대화로부터 평가 세트(evaluation set)를 구축하세요

몇 가지 이상적인 질문만 테스트하는 것은 잘못된 자신감을 심어줍니다.
실제적인 평가 세트(evaluation set)에는 직접적인 질문, 비격식적인 질문, 철자 오류, 두 가지 주제가 결합된 질문, 지원되지 않는 질문, 그리고 정답이 사람에게 전달(human handoff)되어야 하는 질문 등이 포함되어야 합니다.
예를 들어, 배송 정책의 경우 “배송에 얼마나 걸리나요?”, “금요일 전까지 도착할까요?”, “delivery netherlands?”, “내일 도착을 보장할 수 있나요?”와 같은 질문들로 테스트할 수 있습니다. 이러한 질문들은 동일한 소스를 참조할 수 있지만, 서로 다른 수준의 확신을 요구합니다.
답변의 사실적 정확성, 소스 관련성, 완전성, 어조, 그리고 적절한 거절(refusal) 여부를 검토하세요. 실패한 질문들을 저장해 두었다가 콘텐츠나 검색 워크플로우(retrieval workflow)에 의미 있는 변경이 있을 때마다 다시 실행하세요.
새로고침(refresh)을 기능의 일부로 취급하세요.

웹사이트 지식은 노후화됩니다.
가격이 변합니다. 정책이 변합니다. 새로운 페이지가 추가되고 오래된 페이지는 여전히 접근 가능한 상태로 남습니다. 따라서 프로덕션 워크플로우(production workflow)에는 첫 번째 버전이 수동 재학습(manual retraining)에 의존하더라도 새로고침 전략이 필요합니다.
크롤링 시간과 소스 URL을 추적하세요. 삭제된 페이지를 감지하세요. 더 이상 유효하지 않은 소스를 제거할 수 있도록 만드세요. 웹사이트 규모가 크다면, 통제 없이 모든 것을 다시 크롤링하기보다 중요한 섹션에 우선순위를 두세요.
운영 측면의 질문은 간단합니다: 고객 대상 페이지가 변경될 때, 어시스턴트가 새로운 정보를 얼마나 빨리 학습해야 하는가?
단순한 제품 워크플로우

Oscar Chat의 경우, 사용자 대상 프로세스를 네 단계로 줄였습니다: Train 섹션 열기, 웹사이트 URL 추가하기, 콘텐츠가 수집되는 동안 기다리기, 그리고 Playground에서 결과 테스트하기입니다.
이 단순한 인터페이스는 더 중요한 제품 원칙 위에 구축되었습니다: 사용자는 기존 콘텐츠로 시작하여, 시스템이 무엇을 학습했는지 검토하고, 파일이나 승인된 답변을 통해 지식을 개선할 수 있어야 합니다.
이는 모든 소상공인에게 검색 시스템(retrieval system)을 설계하거나 웹사이트를 지식 베이스(knowledge base)로 수동 재현하도록 요구하는 것보다 훨씬 실용적입니다.
최종 요약

AI 지원 어시스턴트의 품질은 소스(source)의 품질, 구조, 그리고 최신성(freshness)에 의해 제한됩니다.
모델 선택도 중요하지만, 모델이 모순된 정책을 바로잡거나 기업이 문서화하지 않은 사실을 제공할 수는 없습니다. 따라서 신뢰할 수 있는 구현을 위해서는 크롤링(crawling), 콘텐츠 정제(content cleanup), 소스 제어(source control), 평가(evaluation), 그리고 인간의 개입(human fallback)을 제품의 핵심 요소(first-class parts)로 다루어야 합니다.

공개 사항: 저는 이 글에서 실무적인 예시로 사용된 제품인 Oscar Chat의 창립자입니다. 더 자세한 정보는 https://www.oscarchat.ai/ai-chatbot/에서 확인하실 수 있습니다.