“주문 C-1042의 다크 초콜릿 세 상자 중 두 상자가 녹아 서로 붙었습니다. 같이 산 견과 초콜릿은 정상이고 주문 쿠폰도 썼습니다. 두 상자만 환불하면 얼마를 돌려줘야 하나요?”
검색 시스템이 이 질문에 답하려면 ‘환불’ 문서 한 편을 찾는 데서 끝나지 않습니다. 고객의 표현을 품질 규정의 용어에 연결하고, 이 주문에 적용되는 버전을 고른 뒤, 실제 결제 내역을 조회해 금액을 계산해야 합니다. 문서는 맞게 찾았는데 정가로 계산하거나, 계산은 맞는데 미래 규정을 적용해도 답은 틀립니다.
벡터 DB가 검색 엔진으로 범위를 넓히는 이유는 이런 질문에서 드러납니다. 의미가 비슷한 내용을 찾는 일과, 업무에 쓸 수 있는 답을 만드는 일 사이에는 여러 단계가 있습니다. 숫자가 복잡하다는 이유만으로 벡터 검색이 필요한 것은 아닙니다. 의미 검색·정확한 식별·조건 확인·계산이 각각 맡을 일을 구분해야 합니다.
turbopuffer의 ‘RIP, vector database’는 이런 확장을 뒷받침하는 저장 구조의 전환을 설명합니다. ANN 벡터 인덱스를 저장 구조의 중심에서 보조 인덱스로 옮기는 v3 설계입니다. 벡터 검색을 없애는 이야기가 아니라, 문서를 여러 방식으로 찾고 처리할 수 있도록 기반을 바꾸는 이야기입니다.
turbopuffer는 객체 스토리지에 데이터를 두고 메모리·SSD 캐시로 검색을 가속하는 벡터·전문 검색 서비스입니다. 공식 아키텍처 설명을 보면 검색 기능뿐 아니라 저장 비용과 캐시 사용을 함께 고려한 구조임을 알 수 있습니다. 앞의 환불 사례는 왜 이런 검색 서비스에 여러 조회 방식이 필요한지 설명하는 예시이고, 글의 중심은 그 요구를 수용하려는 turbopuffer의 저장 구조 전환입니다.
비슷한 문서와 쓸 수 있는 근거의 차이
벡터는 숫자 배열입니다. 검색에서는 임베딩 모델이 질문이나 문서의 특징을 벡터로 표현하고, 가까운 표현을 찾아 관련 후보를 고릅니다. 벡터 DB는 이런 벡터를 저장하고 조회하는 기능을 중심으로 만든 데이터베이스입니다. 본문과 제품군 같은 속성도 함께 저장하고 필터링할 수 있으며, 기능 범위는 제품마다 다릅니다.
이 검색 부품이 자주 쓰이는 구성이 **RAG(검색 증강 생성)**입니다. 외부 자료를 찾아 LLM, 즉 대규모 언어 모델이 답변을 만들 때 근거로 제공하는 방식입니다. 벡터 DB는 질문에 관련된 자료를 찾는 검색 부분을 맡을 수 있고, LLM은 전달받은 원문을 바탕으로 답변을 작성합니다. 자료를 벡터 DB에 넣는 것만으로 LLM이 그 내용을 새로 학습하는 것은 아닙니다. 검색 결과와 프롬프트를 모델에 전달하는 RAG의 공식 설명
앞의 요청을 가상 초콜릿 판매 회사 ‘촤컬릿’의 사내 검색 사례로 이어가 보겠습니다. 회사·주문·금액·날짜·규정은 모두 설명을 위한 가정입니다. 상담 직원이 10월 11일에 주문 C-1042의 부분 환불을 검토하며, 이 직원에게는 상담팀 규정과 담당 주문을 읽을 권한이 있습니다.
고객은 “녹아 서로 붙었다”, “포장에 묻었다”라고 말하지만, 품질 문서에는 **‘냉장 배송 중 열변형’**이라고 적혀 있습니다. 같은 단어를 쓰지 않아도 관련 조항을 후보로 찾을 여지가 있다는 것이 의미 검색의 장점입니다. ‘변심으로 선물 상자를 돌려보내는 경우’도 넓게는 반품 주제와 비슷하지만, 지금 필요한 근거는 품질 손상에 관한 조항입니다.
벡터가 가깝다는 사실은 해당 문서가 이 주문에 적용되거나 직원에게 공개됐다는 보증은 아닙니다. 벡터 검색과 필터의 공식 예시도 두 역할을 구분합니다. 손상 사진의 사실 여부와 보상 승인도 이 글의 벡터 검색이 판정하는 일이 아닙니다. 여기서는 담당자가 배송 중 손상과 두 상자의 환불 대상 수량을 확인한 뒤 금액을 산정한다고 가정합니다.
최신 규정은 주문에 적용되는 버전이어야 합니다
사내 자료실에서 찾은 문서 A, ‘냉장 배송 품질 보상 v3’ 2.1절에는 다음 조항이 있다고 하겠습니다.
10월 1일~31일 주문에 적용합니다. 수령 후 48시간 이내에 접수하고 배송 중 열변형이 확인되면, 확인된 손상 수량에 대해 부분 환불할 수 있습니다. 금액은 쿠폰 정산 지침 R 3.2절, 배송비는 배송비 처리 지침 S 5.1절을 따릅니다.
주문은 10월 9일, 수령은 10월 10일 오후 2시, 접수는 10월 11일 오전 10시입니다. 수령부터 접수까지는 20시간입니다. A가 정한 적용 기준은 주문일이고, 접수 기한은 수령 시각부터 계산합니다. 검색한 날짜 하나로 두 조건을 대신할 수 없습니다.
다른 후보들도 비슷한 품질·반품 용어를 포함합니다. B는 상온 제품의 변심 반품 규정이고, C는 9월 30일까지의 주문에 적용되던 품질 규정입니다. D는 관리자만 읽는 예외 처리 문서이며, E는 10월 10일에 수정했지만 11월 1일 주문부터 적용할 미래 규정입니다. E에서는 접수 기한을 72시간으로 늘리고, 이 유형의 일부 상품 품질 보상에 배송비도 환불하도록 바꾼다고 가정합니다.
먼저 대상을 정확히 확인합니다. 주문번호 C-1042로 권한이 있는 주문을 정확 조회해 냉장 다크 초콜릿의 SKU와 판매 유형을 확인합니다. 주문번호가 비슷한 다른 주문이나 이름이 비슷한 상온 제품을 의미 검색으로 대체해 고르면 안 됩니다. 제품군·판매 유형이 다른 B는 이 질문의 근거에서 제외합니다.
다음으로 반드시 지킬 조건을 붙입니다. 승인된 문서인지, 규정이 정한 기준일에 적용되는지, 로그인한 직원이 읽을 수 있는지 확인합니다. C와 E는 적용 대상 날짜가 맞지 않고, D는 읽기 권한이 없습니다. product_group, approval_status, effective_from, effective_to, read_groups는 이런 조건을 저장하기 위해 설계한 예시 필드이며 엔진의 환불 전용 내장 기능이 아닙니다.
허용된 문서에서 필요한 근거를 모읍니다. A를 찾았다고 검색이 끝나는 것도 아닙니다. A가 참조한 R과 S도 같은 적용 범위와 권한 안에서 확인해야 합니다. R은 할인 배분과 원 단위 처리, S는 일부 상품의 품질 보상 시 배송비 처리에 관한 문서입니다. 조건을 통과하는 현재 문서가 여러 편 남고, 질문에 필요한 조항을 연결하는 일이 남습니다.
이때 ‘열변형’이라는 말이 없는 고객 요청은 의미 검색으로 후보를 넓히고, SKU·문서 식별자·조항 번호 같은 정확한 정보는 키워드 검색과 명시적인 참조 조회로 보완할 수 있습니다. R과 S의 식별자가 원문에 있다면 그 문서를 직접 조회하는 편이 분명합니다. 모든 조회를 벡터 검색으로 바꾸려는 설계는 오히려 오류를 늘릴 수 있습니다.
환불액은 검색 결과와 거래 데이터를 연결해 계산합니다
가상 쿠폰 지침 R 3.2절과 배송비 지침 S 5.1절은 다음처럼 정합니다.
부분 환불액은 주문행에 기록된 할인 반영 실결제액에 환불 수량 ÷ 최초 주문 수량을 곱합니다. 원 단위 미만은 버립니다. 할인 배분은 확정된 결제 기록을 사용하며, 이 유형의 품질 보상으로 쿠폰을 다시 회수하지 않습니다.
일부 상품의 품질 보상에는 최초 배송비를 환불하지 않습니다.
이 규칙을 찾는 일과 규칙에 넣을 숫자를 가져오는 일은 다릅니다. 주문 금액을 비슷한 상담 기록에서 찾거나 모델의 기억으로 채우지 않고, 주문 C-1042의 거래 기록에서 읽어야 합니다. 이번이 첫 환불이고 이전에 환불한 수량과 금액은 없다는 조건도 확인합니다.
가상 주문은 다크 초콜릿 3상자 × 18,000원과 견과 초콜릿 2상자 × 12,000원입니다. 상품 정가 합계는 78,000원이며, 주문 쿠폰 7,000원과 배송비 4,000원을 반영한 실제 결제액은 75,000원입니다.
| 주문 항목 | 최초 수량 | 배분된 쿠폰 | 할인 후 금액 |
|---|---|---|---|
| 냉장 다크 초콜릿 | 3상자 | 4,846원 | 49,154원 |
| 견과 초콜릿 | 2상자 | 2,154원 | 21,846원 |
| 최초 배송비 | — | — | 4,000원 |
다크 초콜릿 주문행의 실결제액 49,154원에 손상 수량의 비율 2 ÷ 3을 적용하면 32,769.333…원입니다. R의 원 단위 버림 규칙에 따라 환불액은 32,769원입니다. S에 따라 배송비 4,000원은 이 환불에 더하지 않습니다. 남는 결제액은 75,000 − 32,769 = 42,231원입니다. 다크 주문행의 잔액 16,385원 + 견과 초콜릿 21,846원 + 배송비 4,000원으로 다시 더해도 42,231원이 되어 금액을 교차 확인할 수 있습니다.
정가 18,000원에 두 상자를 곱해 36,000원이라고 답하면, 쿠폰을 무시해 3,231원 과다 환불한 결과가 됩니다. 미래 규정 E의 배송비 환불 조건까지 적용해 36,769원이라고 답하는 것은 다른 오류입니다. 계산식만 정확하다고 정책 선택까지 정확해지지는 않습니다.
기대하는 답변은 금액에 근거와 전제를 붙입니다.
주문 C-1042에서 배송 중 열변형이 확인된 다크 초콜릿 두 상자의 환불액은 32,769원입니다. 확정된 다크 주문행 실결제액 49,154원에 2/3을 적용하고 원 단위 미만을 버렸습니다. 이번 일부 상품 품질 보상에는 최초 배송비를 포함하지 않습니다.
근거: 주문일에 적용되는 A v3 2.1절, 쿠폰 지침 R 3.2절, 배송비 지침 S 5.1절과 주문 C-1042의 결제 배분 기록. 첫 환불이며 손상 수량이 확인됐다는 전제입니다.
이 사례에서 벡터 검색은 표현이 다른 질문과 관련 조항을 연결합니다. 주문 조회는 확정된 수치를 가져오고, 계산 도구는 선택한 규칙대로 산술을 실행합니다. 일부 검색 엔진이 수치 집계까지 지원하더라도 의미 유사도가 환불액을 계산하는 것은 아닙니다. turbopuffer도 쿼리 문서에서 필터와 숫자 속성의 합계·개수 집계를 구분합니다. 이 예시는 결제 원장을 별도 거래 DB에 두고 승인된 계산 규칙을 적용하는 설계입니다.
벡터 DB를 쓰는 RAG의 흐름
앞의 촤컬릿 사례를 RAG로 구성한다면, 준비할 때 A·R·S 규정을 조항별로 나누고 각 조각의 임베딩을 저장합니다. 조항 원문을 함께 저장하거나 원문을 다시 가져올 수 있는 식별자를 연결하며, 문서 버전·적용 기간·읽기 그룹도 붙입니다. 질문 역시 문서와 비교할 수 있는 임베딩으로 바꿔 관련 조각을 찾습니다. 이때 앞에서 설명한 제품·적용일·권한 조건을 함께 지켜야 합니다.
LLM에 전달하는 핵심은 검색에 사용한 숫자 배열보다 찾아낸 원문입니다. ‘부분 환불 가능’이라는 문장만 주지 않고, 접수 기한과 할인·배송비 조항까지 질문과 함께 제공해야 합니다. 이 사례에는 거래 조회·계산 도구가 확인한 32,769원도 같이 연결합니다. 모델이 근거를 빠뜨리거나 없는 조건을 보태는지는 답변 단계에서 따로 확인합니다. 문서 준비·검색·응답 생성을 연결하는 공식 RAG 예시
- 규정의 검색 자료 준비A·R·S의 원문 조각과 임베딩을 연결하고, 조항 번호·적용 기간·읽기 권한을 저장합니다.
- 질문에 필요한 근거 검색‘녹아 붙었다’로 열변형 조항을 찾습니다. 허용된 적용 범위 안에서 할인·배송비 근거도 모읍니다.
- 원문과 계산 결과로 답변 작성LLM에 질문·선택한 원문·확인된 환불액을 전달합니다. 답변이 금액과 A·R·S의 근거를 함께 설명하는지 봅니다.
숫자 문제만 있다면 SQL이나 스프레드시트로 충분할 수 있습니다. 자료가 작고 용어가 정리돼 있다면 RAG의 검색 부분도 키워드 검색이나 기존 데이터베이스 조회로 구성할 수 있습니다. 벡터 검색이 도움이 되는 지점은 계산 난도가 아니라, 표현이 달라지는 요청에서 관련 근거를 찾는 일입니다. 별도 벡터 DB의 필요성은 이 검색 품질과 자료의 규모·갱신·필터 요구로 판단하면 됩니다.
최근 수정일과 실제 적용일의 차이
E는 A보다 최근에 수정됐습니다. 그러나 10월 9일 주문에 적용되는 것은 A입니다. 문서의 updated_at은 내용을 고친 시점이고, 규정의 적용 시작일과 적용 대상은 별도 정보입니다. 수정일 내림차순으로 첫 문서를 고르면 예정된 규정을 과거 주문에 적용할 수 있습니다.
“지금 주문하면 어떤 보상을 받을 수 있나요”와 “지난달 받은 상품을 보상해 주세요”도 같은 질문이 아닙니다. 규정이 주문일·수령일·접수일 중 어느 시점을 기준으로 삼는지, 변경 규정이 기존 주문에도 적용되는지 원문에서 확인해야 합니다. 이 사례는 A가 주문일을 적용 기준으로 정했기 때문에 그 날짜로 버전을 고릅니다.
접수 기한 48시간은 또 다른 조건입니다. A가 적용되는 주문이라도 접수가 늦거나 수령 시각을 알 수 없으면 자동으로 같은 결과를 낼 수 없습니다. 날짜·수량·손상 확인이 부족할 때 필요한 정보를 요청하는 것도 올바른 답변입니다.
이 구분이 가능하려면 원본 문서의 관리 방식부터 준비돼 있어야 합니다. 승인 상태·적용 대상·참조 조항이 없는데 임베딩 모델만 바꾼다고 업무 규칙을 안정적으로 가려낼 수는 없습니다. ‘최신’은 모델의 눈치에 맡길 표현이 아니라 서비스가 구체적인 조건으로 바꿔야 할 요구입니다.
벡터·키워드·필터가 맡는 서로 다른 일
벡터 검색과 키워드 검색을 함께 쓰는 접근을 하이브리드 검색이라고 합니다. ‘한 덩어리로 붙었다’처럼 표현이 달라지는 질문에는 의미 검색이 도움이 되고, SKU·오류 문자열처럼 정확한 표현이 중요한 질문에는 키워드 검색이 도움이 됩니다. turbopuffer의 하이브리드 검색 가이드는 벡터 검색과 BM25 전문 검색을 결합하고 후보 순위를 합치거나 다시 평가하는 흐름을 설명합니다.
예를 들어 제품 코드가 D-03이라면, 키워드 검색은 그 코드가 들어간 규정 자료를 찾는 데 씁니다. 실제 주문 기록은 확인된 주문번호로 직접 조회합니다.
같은 검색 문제를 푸는 동종 제품의 예로 Qdrant를 들 수 있습니다. Qdrant도 벡터와 payload라는 문서 속성을 관리하고, 속성 필터와 하이브리드 검색을 지원합니다. 이런 공통 기능을 기준으로 같은 질문의 검색 품질과 조건 필터의 동작을 비교할 수 있습니다. 각 엔진이 문서와 색인을 저장하는 방식은 별도의 설계 자료로 확인할 대상입니다.
BM25는 질문에 포함된 단어의 출현 빈도, 그 단어가 전체 문서에서 얼마나 흔한지, 문서 길이 등을 반영해 점수를 매깁니다. 벡터 검색의 거리와 BM25 점수는 단위와 범위가 같지 않습니다. 두 숫자를 그대로 더하면 한쪽 점수 범위가 커서 결과를 과도하게 지배할 수 있습니다.
한 가지 대안이 RRF, 즉 순위 기반 결합입니다. 어떤 문서가 벡터 목록과 키워드 목록에서 각각 몇 번째인지 이용해 결과를 합칩니다. 허용된 후보 가운데 A가 의미 검색에서는 3위, 키워드 검색에서는 1위라면 두 목록의 순위가 함께 신호가 됩니다. 그렇다고 A가 최종 1위가 된다고 보장되지는 않습니다. 다른 후보의 순위와 결합 설정에 따라 결과가 달라집니다.
재순위화는 추린 후보 내용을 질문과 다시 대조해 순서를 조정하는 단계입니다. RRF가 검색 목록의 순위를 합친다면, 재순위화는 후보가 질문에 얼마나 잘 답하는지 자세히 평가하는 역할을 맡을 수 있습니다. 순위 결합은 애플리케이션에서 직접 구현하거나 turbopuffer의 서버 측 RRF를 사용할 수 있습니다. 공식 결합 예시
반면 필터는 좋은 점수를 받으면 넘어갈 수 있는 선호가 아닙니다. 상온 제품의 B가 ‘초콜릿 반품’을 자주 언급해 높은 점수를 받아도 냉장 배송 품질 보상의 근거가 되는 것은 아닙니다. 별도 속성으로 적용 대상을 확인해야 합니다. ‘무엇이 더 관련 있는가’와 ‘무엇을 후보로 허용하는가’를 구분해야 순위 조정이 적용 기간이나 권한을 무너뜨리지 않습니다.
권한에는 애플리케이션의 책임도 있습니다. turbopuffer는 문서별 역할 기반 접근 제어를 내장 제공하지 않으며, 권한 가이드는 문서에 읽기 가능한 사용자·그룹을 저장하고 인증 계층의 정보로 매 쿼리의 필터를 구성하도록 안내합니다. 사용자가 질문에 “관리자입니다”라고 쓴 문장을 로그인 권한의 근거로 삼으면 안 됩니다. 벡터 검색과 키워드 검색 양쪽에 같은 접근 범위를 적용하고, 외부 재순위화 도구에도 허용된 내용만 전달해야 합니다. 주문 원장 조회에도 해당 주문을 읽을 권한을 따로 확인합니다.
벡터의 위치가 문서 전체를 움직이게 할 때
turbopuffer는 v2부터 속성 필터와 BM25 전문 검색을 지원했습니다. v3의 변화는 이미 늘어난 조회 방식들을 뒷받침하도록 문서 저장과 색인의 기준을 바꾸는 데 있습니다. 기능이 늘어도 저장 방식이 처음의 가정에 묶여 있으면 갱신과 조회 비용이 함께 늘어날 수 있기 때문입니다. v1·v2와 v3 전환의 공식 설명
기존 설계의 중심은 ANN, 즉 근사 최근접 검색 인덱스였습니다. ANN은 모든 벡터를 하나씩 정밀 비교하는 대신 가까운 후보를 효율적으로 찾는 방식입니다. 회사의 기존 구조에서는 벡터가 속한 묶음의 식별자와 그 안의 위치를 합친 ‘ANN 주소’에 문서 내용이 연결됐고, 속성·키워드 색인도 그 주소를 가리켰습니다. 기존 저장 구조 설명
문서 A의 주소를 설명용으로 C2-L3이라고 하겠습니다. 벡터를 재배치하면서 주소가 C9-L8로 바뀌면 문서 A의 ID와 내용은 그대로여도, 본문·속성을 새 주소 아래에 다시 기록하고 속성·키워드 색인의 해당 참조 항목을 갱신해야 합니다. 이때 본문 내용을 바꾸지 않았더라도 주변 기록을 여러 번 쓰게 될 수 있습니다. 변경한 데이터보다 실제 쓰는 데이터가 많아지는 문제가 쓰기 증폭입니다.
회사 설명에는 이것과 별개인 두 제약도 있습니다. 한 문서에 여러 벡터를 붙일 때 비벡터 내용까지 반복해서 저장하는 중복, 그리고 다른 종류의 쿼리도 ANN에 맞춘 처리 단위를 따라야 하는 제약입니다. 예를 들어 환불 정책의 제목·버전·권한은 같은데 검색할 부분마다 벡터가 여러 개 있다면, 문서 공통 정보가 어떤 단위로 저장되는지가 비용에 영향을 줍니다.
| 구분 | 역할 | 설명 | 예시 |
|---|---|---|---|
| 저장 중복 | 벡터마다 문서 내용 반복 | 여러 벡터가 같은 문서 내용을 각각 갖는 구조에서는 공통 정보의 복사본이 늘어납니다. | 같은 정책의 여러 벡터에 본문·속성까지 중복되는 경우입니다. |
| 쓰기 증폭 | 재배치가 다른 기록으로 전파 | ANN 주소 변경이 본문·속성의 재기록과 속성·키워드 색인의 해당 참조 항목 갱신으로 이어집니다. | C2-L3을 C9-L8로 옮기며 참조도 함께 고칩니다. |
| 처리 단위 | 다른 쿼리도 ANN 묶음에 종속 | 정렬·집계는 큰 묶음을 읽고 싶어도 문서 배치가 벡터 묶음의 경계를 따를 수 있습니다. | 적용 중인 정책을 부서별로 집계하는 작업은 의미 검색과 요구가 다릅니다. |
이 마지막 항목에서 말하는 ‘벡터화 실행’은 문장을 임베딩으로 바꾼다는 뜻이 아닙니다. 여러 값을 묶어서 연속 처리하는 실행 방식입니다. 벡터 검색이라는 이름에 익숙하면 두 뜻을 혼동하기 쉽지만, 여기서는 CPU가 데이터 묶음을 효율적으로 처리할 수 있느냐가 문제입니다.
v3의 설계 방향은 문서의 기본 저장 주소를 ANN 배치에서 분리하고 ANN을 여러 조회 경로 중 하나로 만드는 것입니다. 이 설명만으로 구체적인 새 기본 키나 모든 쿼리의 성능을 단정할 수는 없습니다. 핵심은 한 검색 방식의 배치가 다른 조회·갱신 방식까지 결정하는 결합을 줄이려는 데 있습니다. 설계 변경의 목표와 개발 단계
v3 벤치마크를 읽을 때 확인할 조건
구조를 더 유연하게 바꿨다고 새 버전이 모든 작업에서 즉시 빨라지는 것은 아닙니다. v3 개발 페이지는 테스트를 통과한 구현을 운영 버전 v2보다 빠르게 만들기 위해 최적화하는 과정을 공개합니다. 일부 작업의 개선과 전체 운영 성능 우위는 서로 다른 주장입니다.
그래프의 값은 같은 작업에서 v3의 p90 지연시간을 v2의 p90 지연시간으로 나눈 비율입니다. p90은 측정 요청의 90%가 그 시간 이하에서 끝났다는 뜻입니다. 평균이나 최악의 요청 시간이 아니며, 비율의 ‘2’도 2ms가 아닙니다.
아래 숫자는 읽는 법을 설명하기 위해 v2의 p90을 100ms로 둔 산술 예시입니다. 실제 turbopuffer 측정값은 아닙니다.
| v2 p90 | v3 p90 | v3 ÷ v2 | 지연시간 관계 |
|---|---|---|---|
| 100ms | 50ms | 0.5 | v3가 절반의 시간 |
| 100ms | 100ms | 1 | 같은 시간 |
| 100ms | 200ms | 2 | v3가 두 배의 시간 |
측정 조건도 같이 봐야 합니다. 공식 방법론은 문서 1,000만 개에 초당 8개 쿼리를 10분 동안 보내는 조건을 제시합니다. hot 측정은 캐시 적중률이 100%가 된 뒤, cold 측정은 캐시를 끄고 진행합니다. 벡터 검색과 전문·하이브리드 검색의 데이터셋도 같지 않습니다. 각 결과를 하나의 ‘전체 검색 속도’로 합쳐 읽을 수 없는 이유입니다. 측정 방법론
개발 로그가 발표된 날짜와 성능 변화가 측정된 날짜도 구분해야 합니다. 초기 구현 대비 큰 개선율이 나왔다고 해서 운영 v2보다 그만큼 빠르다는 뜻은 아닙니다. 엔진을 고르는 팀이라면 자사 문서의 양·필터 조건·질문 분포·캐시 상태로 비교할 이유가 있습니다.
검색 실패를 어디에서 고칠지 찾기
부분 환불 답변이 틀렸다면 먼저 검색 결과와 최종 답변을 따로 보관해 비교하는 편이 좋습니다. 최종 문장만 보면 정답 문서를 못 찾은 것인지, 찾은 문서를 잘못 읽은 것인지 구별하기 어렵습니다.
정답 A가 후보에 아예 없으면 원본이 검색 저장소에 들어왔는지, 필터가 지나치게 좁은지, 문서를 나눈 경계가 적절한지부터 확인합니다. A가 후보에 있지만 뒤로 밀렸다면 순위 결합과 재순위화가 대상입니다. A·R·S가 모델에 전달됐는데 접수 기한이나 할인 반영 조건이 답에서 빠졌다면 근거 사용과 답변 생성을 봐야 합니다. 규정은 맞는데 36,000원으로 계산했다면 거래 조회와 계산 입력부터 확인합니다.
문서 분할도 앞의 규정에서 구체적으로 점검할 수 있습니다. ‘손상 수량을 부분 환불할 수 있습니다’와 ‘수령 후 48시간 이내 접수해야 합니다’를 서로 다른 조각으로 나누고 앞쪽만 찾았다면, 최신 문서를 골라도 잘못된 답이 생깁니다. 제목·대상 제품·버전·적용 기간을 각 조각에 연결하고 조건과 예외가 함께 읽히도록 나눌 필요가 있습니다. 공식 청킹 가이드도 너무 짧은 조각이 맥락을 잃을 수 있고 문서의 의미 있는 경계를 존중해야 한다고 설명합니다.
갱신 문제는 검색 모델의 문제와 나눠야 합니다. 원본의 A를 새 규정으로 바꿨는데 검색 복사본에 본문만 바뀌고 적용 기간은 예전 값이면, 필터는 잘못된 정보로 동작합니다. 아직 엔진에 전달하지 않은 변경을 검색 엔진이 스스로 반영할 수는 없습니다. 본문·버전·권한·청크의 갱신, 삭제, 실패한 전달의 재처리까지 같은 검수 범위에 넣어야 합니다.
- 질문 표현을 바꾸기‘초콜릿이 붙었다’와 ‘냉장 배송 중 열변형’이 같은 품질 조항으로 이어지는지 확인합니다.
- 적용 버전을 교체하기11월 1일 주문·11월 2일 오후 2시 수령·11월 3일 오전 10시 접수로 사례 전체 날짜를 옮겨 E가 선택되고 배송비 포함 36,769원이 계산되는지 확인합니다. 원래 10월 주문은 A와 32,769원을 유지해야 합니다.
- 권한을 바꾸기상담팀 읽기 권한을 회수한 계정에는 해당 문서 본문이 검색·재순위화·답변에 전달되지 않는지 확인합니다.
- 근거가 없는 질문 넣기문서에 없는 ‘환불금이 정확히 며칠 뒤 입금되나요’에 처리 일수를 만들어 답하지 않는지 확인합니다.
결과가 없을 때는 제품·적용 기간·권한을 풀어 다른 문서로 채우지 않습니다. 현재 접근 가능한 자료만으로는 확인할 수 없다고 알리고, 필요한 제품이나 주문 정보를 요청하는 편이 맞습니다. 실제 검증에서 사용할 정답 문서와 기대 행동을 이렇게 적어 두면 엔진이나 모델을 바꾼 뒤에도 같은 기준으로 비교할 수 있습니다. 금액 검증에는 정가 계산의 오답과 쿠폰 배분을 반영한 정답, 원 단위 처리와 환불 이력도 함께 넣습니다.
엔진 선택은 실제 질문의 요구에서
벡터 검색만으로 충분한 경우도 있습니다. 변경이 드문 소규모 자료에서 대략 비슷한 항목을 추천하는 용도라면 단순한 구성이 운영에 유리할 수 있습니다. 반면 촤컬릿 사례처럼 정확한 제품·적용 시점·권한·원문 조항이 모두 중요하면, 그 조건을 함께 실행하고 갱신할 수 있는지부터 봐야 합니다.
이미 사용하는 데이터베이스가 필요한 검색 품질과 부하를 감당한다면 그 안에서 시작할 수 있습니다. 별도 엔진이 검색 방식이나 처리량에서 이점을 주더라도 문서 복사본의 동기화, 장애 복구, 삭제와 권한 변경 반영에는 추가 책임이 생깁니다. 속도 비교와 함께 누가 이 변경을 전달하고 실패를 재처리할지까지 정해야 선택을 평가할 수 있습니다.
turbopuffer가 벡터 중심 저장 구조를 바꾸는 이유도 여기에 있습니다. 조회 방식은 다양해졌는데 문서 배치를 ANN 주소에 묶어 두면, 벡터 재배치가 다른 색인의 갱신까지 움직이고 집계에 필요한 처리 단위도 제한됩니다. v3는 이 결합을 줄여 여러 검색·갱신·집계 경로를 수용할 토대를 바꾸려는 전환입니다. 촤컬릿 상담 직원에게 필요한 것은 그 주문에 적용되는 원문·읽을 수 있는 거래 기록·규칙에 따른 계산 결과입니다. 이처럼 의미 검색 너머의 요구를 어떤 구조로 처리하는지와 실제 측정 결과를 함께 보는 편이 정확합니다.
VIEW—
