Jev는 웹사이트 검색보다 틀린 페이지를 10분의 1만 골랐다

테스트 질문 하나를 보자. 여러 종류의 수리 업무를 하는 회사에 고객이 전화한다.

“안녕하세요. 지난주에 배관공이 왔는데 작업에 문제가 있어요. 아직도 물이 새는데 누구에게 연락해야 하나요?”

AI 전화 응대 시스템은 설계된 대로 회사 웹사이트를 검색해 관련도가 가장 높은 페이지를 언어 모델에 전달한다. 하지만 운영 중인 임베딩 검색이 고른 페이지는 ‘믿을 만한 배관공을 찾는 법’이라는 블로그 글이었다. 불만을 품은 고객과 통화하는 언어 모델에 건넬 페이지로는 최악에 가까웠다.

이런 사례는 한 번으로 끝나지 않았다. 10월 초 실행한 테스트에서 검색 시스템은 전화 문의 168건 가운데 3분의 1에 잘못된 페이지를 전달했다. 대신 글을 생성하지 못하고 목록에서 페이지를 고르는 모델을 시험했다. Jev는 잘못된 페이지를 3%의 문의에만 전달해 기존 검색의 33%보다 10분의 1 수준이었다. 정답 페이지를 첫 번째로 고른 비율은 88%로 기존 검색의 70%보다 높았다. 예상하지 못한 점은 웹사이트에 답이 없다는 사실도 알아냈다는 것이다.

Sayora는 영국의 배관·부동산·전기·바 등의 소규모 사업체를 대신해 전화를 받는다. 대부분은 예약, 메시지, 토요일 영업 여부처럼 일상적인 문의다. 흥미로운 질문은 사업체 자체에 관한 것이다. 감정 평가가 무료인지, 연수기 설치를 하는지, 개를 데려와도 되는지 등을 묻는다. 답은 대개 사업체 웹사이트에 있다.

현재는 사이트가 작으면 홈페이지나 최대 8개 페이지를 프롬프트에 그대로 넣는다. 사이트가 더 크면 모든 페이지를 1,200자 단위로 나누고 200자씩 겹치게 한 뒤, OpenAI의 text-embedding-3-large로 768차원 임베딩을 만든다. 고객이 말할 때마다 발화를 임베딩하고, 후속 질문에는 직전 차례를 포함한 버전도 만든다. 코사인 유사도가 0.36을 넘는 가장 가까운 청크를 모델에 전달한다. 흔히 쓰는 검색 증강 생성(RAG) 방식으로, 출시해 사용할 정도로 작동했지만 늘 마음에 걸리는 점이 있었다.

웹사이트 페이지를 통째로 고른 이유

소규모 사업체의 웹사이트는 문서 더미가 아니다. 사업을 아는 사람이 이미 페이지별로 정리해 두었고, 각 페이지는 보일러 정비, 요금, 직원, 크리스마스 메뉴처럼 한 가지 주제를 다룬다. 페이지를 잘게 쪼개고 코사인 유사도로 의미를 다시 조합하는 방식은 거꾸로 느껴졌다.

대신 페이지 전체를 유지하고 각 페이지의 짧은 설명을 작성했다. 전화 응대 시스템은 모르는 내용이 나오면 “확인해 보겠다”고 말하고 도구를 호출한다. 도구는 모델에 객관식 질문을 던져 고객의 문의에 답할 페이지를 고르게 하며, 선택지에는 ‘해당 페이지 없음’도 포함한다. 가장 적합한 페이지 한두 개를 언어 모델에 전달하고, ‘없음’을 고르면 응대 시스템이 모른다고 말한 뒤 질문을 담당자에게 넘긴다.

테스트에는 부동산 중개업체의 74페이지 사이트에서 실행한 조회 사례도 포함됐다. 페이지를 고르는 모델은 TypeSafe가 9월 15일 출시한 의사결정 모델 Jev다. Jev는 텍스트를 생성하지 않는다. 상태 정보와 유형이 지정된 질문을 보내면 각 선택지의 확률과 함께 선택 결과를 반환한다. 선택 질문 하나에는 최대 255개 선택지를 넣을 수 있고, 요청 하나는 최대 64k 토큰을 받는다. 입력 토큰 100만 개당 비용은 0.042달러이며 출력 비용은 없다. 100페이지 사이트에서 조회 한 번에 드는 비용은 1센트의 20분의 1 정도다.

Jev를 처음 접한다면 Jev는 무엇에 유용한가?에서 쉬운 설명을 볼 수 있다.

이 작업과 Jev의 입력 형태는 잘 맞는다. 선택지는 페이지이고, 상태는 고객의 발화이며, ‘해당 페이지 없음’도 선택지 하나다. 마지막 선택지는 페이지 순위를 매기는 것보다 더 중요하게 작용했다.

테스트 방법과 결과

고객사 웹사이트 네 곳을 골라 페이지 선택에 필요하지 않은 페이지를 제외했다. 매물 개별 목록은 별도 피드가 다루므로 뺐다. ‘[지역]의 전기기사’처럼 거의 똑같은 지역별 방문 페이지도 제외했다. ‘해당 지역을 방문하나요?’라는 문의에는 같은 페이지 31개 중 하나를 고르는 것보다 서비스 지역 목록이 더 적합하기 때문이다. 남은 사이트는 바와 레스토랑 22페이지, 부동산 중개업체 74페이지, 전기업체 75페이지, 여러 종류의 수리 업무를 하는 회사 232페이지였다.

Claude Haiku 4.5가 모든 페이지를 한 번씩 읽고 설명을 작성했다. 설명은 제목, 경로, 사실에 기반한 30단어 요약, 고객이 물을 만한 질문 몇 가지로 구성됐으며 페이지당 약 100토큰이었다. 별도로 Claude Opus 5.5는 설명이 아니라 페이지 본문을 읽고 실제 고객이 할 법한 질문을 만들었다. 질문은 총 168개로, 사이트에서 답할 수 있는 질문 128개와 답할 수 없는 질문 40개였다. 답할 수 있는 질문 중 4분의 1에는 대화 두 차례 뒤에 “그러면 가격은 얼마인가요?”처럼 이어지는 후속 질문도 붙였다.

아홉 가지 페이지 선택 방식이 모든 질문을 처리했다.

• Jev: 사이트의 모든 페이지와 ‘없음’을 선택지로 둔 질문 하나
• 설명을 짧게 만든 Jev: 제목과 요약만 사용하거나 제목만 사용
• 임베딩으로 후보를 좁힌 뒤 Jev 사용: 임베딩 상위 40개 페이지 중 Jev가 선택
• GPT-6 Luna: 같은 페이지 목록에서 최대 3개의 페이지 ID 또는 ‘없음’을 선택
• 페이지 설명 임베딩: Jev가 읽은 설명을 임베딩
• 청크 임베딩: 현재 운영 중인 검색 방식을 그대로 사용
• BM25: 설명과 페이지 본문을 대상으로 한 키워드 검색

평가는 여러 선택기의 결과를 모아 진행했다. 각 질문에서 선택기 중 하나라도 상위 3위 안에 넣은 페이지를 모아 심사자 Claude Opus 5.5가 실제 페이지 본문을 읽고 전화 응대 시스템이 그 내용으로 답할 수 있는지 판단했다. 심사 결과는 1,668건이다. 특정 선택기는 다른 선택기가 고른 페이지를 기준으로 평가하지 않았다. 심사자가 답할 수 없다고 만든 질문에서 답을 찾거나, 답할 수 있다고 만든 질문에서 답을 찾지 못한 경우에는 질문의 분류를 바꿨다. 이런 변경은 6건이었다.

선택기가 ‘전달’하는 페이지는 ‘없음’을 고르지 않는 한 첫 두 페이지다. 아래 신뢰구간은 질문 단위 쌍체 부트스트랩으로 계산했다.

답할 수 있는 질문 128개 중 Jev는 88%에서 정답 페이지를 첫 번째로 골랐고, 95%에서는 상위 3개 안에 넣었다. 운영 중인 검색은 첫 번째 정답률이 70%였다. 차이는 18%포인트이며 95% 신뢰구간은 11~26%포인트다. 상대적으로는 26% 높은 수치다. Jev가 본 것과 똑같은 설명을 임베딩한 비교가 더 공정한데, 이 경우에도 Jev의 우위는 14%포인트(7~21%포인트)였다. 키워드 검색은 53~57%로 가장 낮았다.

Jev가 답이 없을 때 멈춘다

페이지 순위는 작업의 절반에 불과하다. 전화 통화에서는 질문에 답하지 않는 페이지를 언어 모델에 건네는 실수가 더 위험하다. 유창한 모델이 그 페이지를 바탕으로 답을 지어낼 수 있기 때문이다. 그러면 전화 응대 시스템이 안내 글에 나온 평균 가격을 해당 사업체의 실제 가격인 것처럼 말할 수 있다.

잘못된 페이지를 전달했다는 것은 선택기가 페이지를 반환했지만 처음 전달한 두 페이지 중 어느 것도 질문에 답하지 않았다는 뜻이다. 운영 기준값 0.36을 적용한 청크 검색은 전체 질문의 33%에서 잘못된 페이지를 전달했다. 사이트가 답할 수 없는 질문 40개 중 웹사이트에 답이 없다고 판단한 경우는 9개뿐이었다. Jev는 전체 질문의 3%에서 잘못된 페이지를 전달했고, 40개 중 38개에서 ‘웹사이트에 없음’을 골랐다.

기준값을 높이면 되지 않느냐는 반론에 대응해 여러 기준값을 시험했다. 같은 질문으로 기준값을 조정해 청크 검색에 유리한 조건을 줬는데도, 전체 과정에서 올바르게 답한 비율은 가장 높을 때 73%였다. 잘못된 페이지를 전달한 비율도 여전히 15%였다. 기준값을 따로 조정하지 않은 Jev는 정답률 90%, 잘못된 페이지 전달률 3%를 기록했다. Jev의 ‘없음’은 유사도 점수의 기준값이 아니다. 모델이 모든 페이지와 비교해 가중치를 따지는 하나의 선택지다.

‘없음’은 안전성 외에도 쓸모가 있다. 이 선택지가 나올 때마다 고객이 묻지만 웹사이트에는 없는 정보를 발견하게 된다. 사업주가 알고 싶어 할 만한 정보 공백이다.

웹사이트 검색에서 임베딩이 놓친 페이지

청크 검색이 잘못된 페이지를 첫 번째로 고른 질문 39개를 모두 확인했다. 그중 23개는 일반 안내서나 블로그 글로 연결됐다. “전기 인증서를 받을 수 있나요?”라는 질문에 ‘영국에서 집 배선을 다시 하는 법’을, 누수 불만에 ‘믿을 만한 배관공을 찾는 법’을 골랐다. 긴 안내 글은 사업체가 직접 올린 짧은 페이지보다 고객 질문과 겹치는 단어가 많아 코사인 유사도 경쟁에서 앞섰다.

Jev는 페이지 목록을 사람이 읽듯 살펴보는 편이었다. Jev가 틀린 경우는 대개 서로 비슷한 페이지를 혼동했을 때였다. 예를 들어 ‘Part P 인증서’ 대신 ‘공인 전기기사’를 고르는 식이다. Jev가 첫 페이지를 잘못 고른 16건 중 안내 글을 선택한 사례는 하나뿐이었다.

테스트 질문 여섯 개와 페이지 이름은 사업체를 익명으로 유지하기 위해 일부 수정했다.

Jev의 뚜렷한 약점은 페이지 설명을 글자 그대로 읽는다는 점이다. 배관 설치 페이지에 연수기 관련 내용이 있었지만 설명에는 그 내용이 없어 Jev는 ‘없음’을 골랐다. 반면 페이지 본문을 읽는 청크 검색은 해당 페이지를 찾았다. 요금 페이지의 열쇠 복사 서비스, 전기 설치 페이지의 전기차 충전기도 같은 방식으로 놓쳤다. 설명에 고객이 구체적으로 물을 만한 항목을 포함하는 것이 해결책이다.

언어 모델이 직접 페이지를 고르면 어떨까

GPT-6 Luna에 같은 페이지 목록을 주고 페이지 ID를 최대 3개 선택하거나 ‘없음’을 고르도록 했다. OpenAI의 새 Decisions API는 튜닝된 GPT-6 Luna를 기반으로 한다고 알려져 있다. 아직 API에 접근할 수 없어 이 비교는 속도가 아니라 판단을 대신 살펴본다.

Luna의 첫 번째 정답률은 86%로 Jev의 88%와 비슷했다. 차이는 2%포인트이며 구간은 −4~+7%포인트였다. 다만 응답은 더 느렸다. 추론 강도를 낮게 설정했을 때 중앙값은 0.66초, 95백분위는 1.27초였다. Jev는 각각 0.28초와 0.42초였다. Luna는 ‘없음’도 덜 선택했다. 답할 수 없는 질문의 80%를 찾아냈고, 잘못된 페이지를 전달한 비율은 8%였다.

Luna는 질문을 놓쳤을 때 그럴듯한 페이지를 골랐다. 바에 어린이 메뉴가 없는데 어린이 메뉴를 묻자, 음식 메뉴를 확신을 담아 전달했다. 전화 응대 시스템이 부모에게 성인용 메뉴를 읽어 주면서 어린이용 메뉴가 있는 것처럼 암시하는 상황이다.

임베딩과 Jev를 함께 쓰는 방법

테스트에서 좋은 결과 중 일부는 두 방식을 함께 사용했을 때 나왔다. 임베딩으로 페이지 40개를 추린 뒤 Jev가 그중에서 고르면 첫 페이지 정답률은 88%였고, 처리 시간은 0.25초였다. 232페이지 사이트에서 후보를 100개로 잡았을 때는 첫 페이지 정답률이 95%였고 잘못된 페이지를 전달한 경우가 없었다.

임베딩은 “이 근처 어딘가”를 찾는 데 유리하고 Jev는 “바로 이 페이지”를 고르는 데 유리하다. 둘 중 하나만 택할 필요는 없다.

페이지 수와 요청 시간

Jev의 선택 질문은 최대 255개 선택지를 받는다. 고객 기록에 있는 사업체 웹사이트 449곳 중 사이트맵을 공개한 곳은 353곳이었다. 사이트맵 페이지 수의 중앙값은 14개였고, 95%는 255페이지 이하였다. 소규모 사업체의 웹사이트도 대체로 작았다.

선택지 수가 제한에 걸리는지 확인하기 위해 페이지 목록을 16개부터 232개까지 늘려 시험했다. 각 목록은 질문과 같은 사이트 구역에 있는 유사 페이지를 우선 채워, 선택지가 늘어날 때마다 그럴듯한 오답 후보가 추가되도록 했다. 모든 목록에는 정답 페이지와 같은 구역의 유사 페이지를 넣었으며, Jev와 임베딩이 같은 목록에서 선택하도록 했다.

유사한 페이지가 늘수록 정확도는 낮아졌다. 가장 큰 사이트에서 Jev의 정확도는 선택지 16개일 때 100%, 232개일 때 92%였다. 정답 페이지는 매번 상위 3개 안에 들었다. 같은 목록에서 임베딩은 89%에서 74%로 하락했다. 서비스 페이지가 서로 비슷한 전기업체 사이트는 두 방식 모두 가장 어려운 사례였다.

영국에서 노트북으로 측정한 Jev 요청의 중앙 처리 시간은 선택지 수나 질문 수보다 입력 토큰 수에 따라 달라졌다. 약 2,000토큰인 16페이지 목록은 0.23초, 24,000토큰인 232페이지 목록은 0.43초가 걸렸다. 전체 측정에서 지연 시간은 대략 0.23초에 입력 토큰 1,000개당 7밀리초를 더한 값에 맞았다.

254페이지를 넘으면 질문을 하나보다 많이 사용해야 한다. 이를 1,253페이지를 보유한 The Podcast Host 사이트에서 시험했다. 구역을 고르는 질문과 각 구역의 페이지를 고르는 질문을 하나의 요청에 넣었다. 설명이 작성된 페이지 553개와 63,000토큰을 처리했으며, 토큰 한도 바로 아래에서 0.63초 만에 답했다. 질문을 더 넣어도 시간은 늘지 않았고 토큰 수만 영향을 줬다.

페이지 설명이 성능을 좌우한다

전체 과정에서 올바르게 답한 비율은 올바른 페이지를 전달하거나 사이트에 답이 없을 때 ‘없음’을 고른 비율이다. Jev는 설명에 적힌 정보만 안다. 페이지 제목만 사용하면 첫 페이지 정답률이 9%포인트, 전체 정답률이 16%포인트 떨어졌다. 제목에 한 줄 요약을 더한 방식은 예시 질문까지 포함한 전체 설명과 비슷하게 작동했으므로 예시 질문은 생략할 수 있다. Claude Haiku로 요약을 쓰는 비용은 페이지당 약 0.002달러다. 페이지가 바뀔 때만 다시 작성하면 된다.

후속 질문도 처리한다

전화 통화에서 고객은 앞서 한 말을 반복하지 않는다. “그러면 가격은 얼마인가요?”는 앞선 두 차례 대화가 있어야 뜻이 통한다. Jev에는 앞선 두 차례를 상태로, 고객의 마지막 발화를 질문으로 제공했다. 그 결과 정답 페이지를 첫 번째로 고른 비율은 91%로, 질문을 명확하게 다시 쓴 뒤 제공했을 때와 같았다. 후속 질문에 맞춰 검색어를 확장하는 기존 검색은 정답률이 78%에서 72%로 떨어졌다.

따라서 도구를 호출하기 전에 고객의 말을 다시 작성할 필요 없이 실제 발화를 그대로 전달할 수 있다.

가장 어려웠던 부분은 크롤러였다

페이지를 고르는 일은 쉬웠다. 실제 소규모 사업체 웹사이트를 읽는 과정에서는 사이트마다 다른 문제가 발생했다.

테스트에 넣지 못한 사이트가 두 곳 있었다. 중고차 판매업체 사이트는 정직한 크롤러에 내부 페이지마다 빈 ‘202 Accepted’ 응답을 보냈다. 운영 중인 스캐너도 같은 응답을 받기 때문에 해당 고객사의 전화 응대 시스템은 홈페이지 정보만 알고 있다. 봇 차단을 피하려고 크롤러를 브라우저처럼 꾸미지는 않는다. 사이트 운영자가 크롤러를 허용 목록에 추가해야 접근할 수 있다. 또 다른 전기업체 사이트는 AI 사이트 제작 도구로 만들어져 브라우저 안에서 콘텐츠를 그렸다. 일반적인 페이지 요청으로는 빈 껍데기만 가져왔다.

테스트에 넣을 수 있었지만 문제가 있었던 사이트도 두 곳이다. 부동산 중개업체의 페이지 제작 도구는 본문 추출기를 혼란스럽게 했다. 감정 평가 페이지, 직원 소개 페이지, 지역별 매물 판매 페이지의 본문으로 쿠키 배너를 반환했다. 사이트 전체에서 반복되는 줄을 본문에서 제외하고 페이지 본문으로 대체하자 91페이지 중 49페이지를 복구했다.

The Podcast Host의 CDN은 병렬 요청 6개를 몇 분간 보낸 뒤 429 응답을 반환하기 시작했다. robots.txt가 검색 엔진에 초당 한 번 요청하라고 안내한 점을 반영해 1.2초마다 한 번 요청하자 1,253페이지를 약 25분 만에 모두 가져왔다.

이번 테스트가 말해 주지 않는 것

• 질문은 실제 통화에서 나온 것이 아니다. 모델이 페이지 본문을 바탕으로 작성했다. 고객처럼 들리지만 실제 통화 기록은 다음 테스트에서 살펴볼 예정이다.
• 관련성 평가는 모델 하나가 맡았다. Jev와 청크 검색의 판단이 엇갈린 사례 중 다섯 건을 사람이 직접 확인했고 다섯 건 모두 심사 모델의 판단이 맞았다. 나머지는 확인하지 않았다.
• 표본은 작다. 사이트마다 질문이 약 35개이므로 특정 사이트의 수치는 어느 쪽으로든 15%포인트가량 흔들릴 수 있다. 통합 수치와 신뢰구간을 중심으로 봐야 한다.
• 한 장소에서 한 번씩 실행했다. 모든 선택기를 영국의 노트북에서 한 번 실행했다.
• 운영 중인 청크 검색이 가능한 최선의 임베딩 설정은 아니다. 재순위화 모델, 하이브리드 검색, 더 똑똑한 청킹으로 격차를 줄일 수 있다. 이번 테스트는 실제 운영 설정과 Jev가 읽은 것과 같은 설명을 대상으로 한 임베딩을 비교했다.
• Jev는 출시된 지 3주 된 모델이다. 실제 적용하더라도 임베딩 후보 추리기를 대체용으로 남겨 둘 예정이다.
• 대형 사이트 테스트는 끝나지 않았다. 정확도 표에 The Podcast Host의 1,253페이지를 넣고 싶었지만 페이지 설명을 작성하던 중 API 크레딧이 바닥났다.

다음 단계

다음에는 실제 통화 기록에서 나온 질문을 시험한 뒤 실시간 통화에서 검증할 계획이다. 결과가 유지되면 전화 응대 시스템이 홈페이지뿐 아니라 사업체의 전체 웹사이트를 읽고, 사업주가 활용 가능한 페이지를 선택하도록 할 예정이다. ‘웹사이트에 없음’으로 분류된 항목은 사업주가 답할 질문으로 전달할 수 있다. 접근 권한을 얻으면 OpenAI의 Decisions API도 같은 방식으로 시험하고 싶다.

검색에 의사결정 모델을 써 봤거나 놓친 점이 있다고 생각한다면 의견을 들려 달라고 했다.

전체 수치

‘첫 페이지 정답률’과 ‘상위 3개’는 답할 수 있는 질문 128개를 기준으로 한다. ‘전체 정답률’은 올바른 페이지를 전달하거나 사이트에 답이 없을 때 ‘없음’을 선택한 비율로, 전체 168개 질문을 기준으로 한다. ‘사이트에 없다고 판단’은 사이트가 답할 수 없는 질문 40개를 기준으로 한다. 임베딩 지연 시간에는 쿼리 임베딩 한 번과 메모리 내 검색이 포함된다.

테스트 세부 조건은 다음과 같다. 웹사이트는 매물 목록과 지역별 방문 페이지를 제외한 소규모 사업체 네 곳으로, 페이지 수는 22~232개였다. 업체 이름은 공개하지 않았다. 질문은 총 168개로 사이트가 답할 수 있는 질문 128개와 답할 수 없는 질문 40개로 구성했고, 이 가운데 32개는 대화 두 차례 뒤에 이어지는 후속 질문으로도 물었다. 페이지 설명은 Claude Haiku 4.5가 페이지마다 한 번 작성했으며, 제목·경로·30단어 요약·예시 질문 세 개를 포함해 약 100토큰이었다. 심사에서는 선택기 중 하나라도 상위 3위에 넣은 페이지의 본문을 Claude Opus 5.5가 읽었다. 총 1,668건을 평가했다.

Jev 버전은 jev-1.13.0이다. 고객 발화를 상태로 제공하고 페이지들과 ‘없음’을 선택지로 둔 질문 하나를 사용했다. 임베딩에는 text-embedding-3-large의 768차원 벡터를 썼다. 운영용 청크는 1,200자에 겹침 200자이며 기준값은 0.36이었다. GPT-6 Luna는 Azure의 채팅 API를 통해 추론 강도 ‘low’로 실행해 페이지 ID를 최대 세 개 고르거나 ‘없음’을 선택하도록 했다. ‘전달’은 ‘없음’을 선택하지 않았을 때 반환한 처음 두 페이지를 뜻한다. 신뢰구간은 질문을 기준으로 4,000회 쌍체 부트스트랩을 실행했다. Jev 요청은 1,449건, 입력 토큰은 1,060만 개였고 비용은 약 0.45달러였다.