9월 18일 금요일

검색 시스템은 질의마다 달라지는 정보 해상도와 데이터 온도, 탐색 난도를 어디에서 흡수해야 하는가?

세 원문은 검색을 하나의 벡터 조회가 아니라 서로 다른 시간축의 결정으로 분해한다. 첫째, 인덱싱 시점에는 미래 질의를 모르므로 한 가지 청크 크기를 고정하면 구체적 사실과 넓은 맥락 중 하나를 체계적으로 잃는다. 둘째, 운영 시점에는 모든 데이터를 같은 메모리 계층과 파티션에 두면 접근 빈도가 다른 데이터가 캐시를 두고 경쟁한다. 셋째, 질의 실행 시점에는 고정된 재작성·검색·재순위화 파이프라인이 결과 부족을 알아도 스스로 재검색하지 못한다. 따라서 표현은 여러 해상도로 보존하고, 저장은 실제 업무 경계와 접근 온도에 맞추며, 탐색은 검증 가능한 보상 아래 질문 난도에 따라 반복 횟수를 바꾸는 구조가 필요하다. 이 세 층은 서로 대체재가 아니다. 검색 에이전트가 좋아져도 잘못된 표현과 저장 경계를 복구하는 데 비용을 쓰게 되고, 좋은 인덱스도 행동 루프가 없으면 롱테일 질의에서 같은 실패 경로를 반복한다.

1. 01

   표현 경계: 청크 선택을 검색 시점으로 미룬다

   고정 청킹은 문맥 보존과 세부 신호 보존 사이의 손실 압축이다. 50·100·200·500·1,000·2,000토큰 인덱스를 비교한 실험에서는 같은 코퍼스 안에서도 질문마다 최적 크기가 달랐고, 질의별 최적 결과를 사후 선택한 오라클과 단일 크기 사이에 약 20~40%의 recall 여지가 나타났다. 현실의 구현은 정답을 아는 오라클 대신 모든 해상도를 병렬 검색한 뒤, 서로 비교하기 어려운 유사도 점수를 직접 합치지 않고 청크가 속한 부모 문서의 순위를 RRF로 융합한다. 얻는 것은 모델 재학습 없이 회수하는 recall이고, 지불하는 것은 여러 인덱스를 위한 약 2~5배의 메모리다. 따라서 먼저 실제 질의 로그를 좁은 사실형과 넓은 맥락형으로 나눠 recall@K를 측정해야 한다.

2. 02

   저장 경계: 질의 단위와 격리 단위를 맞춘다

   법률 검색 사례는 프로젝트를 약 4,000개 Postgres 파티션에 빈 패킹하면서 핫·콜드 프로젝트가 섞였고, 파티션 재적재로 P99가 약 100밀리초에서 20초까지 악화된 실패를 보여준다. 프로젝트와 관할권을 각각 네임스페이스로 바꾸자 검색 단위가 암호화 키·버킷·물리적 격리 단위와 일치했고, 유휴 데이터는 오브젝트 스토리지에 남길 수 있었다. 이 토폴로지에서는 상위 벡터 centroid를 메모리에, 리프를 NVMe에 두는 계층형 트리와 왕복 최소화가 중요하다. S3의 약 1MB Blob P99가 약 200밀리초인 조건에서는 그래프 노드를 따라가는 무작위 왕복보다 세 번 안팎의 큰 왕복을 목표로 하는 편이 경제적이다.

3. 03

   행동 경계: 검색을 검증 가능한 하위 에이전트로 분리한다

   범용 에이전트는 작업 토큰의 약 30~50%를 검색에 쓰고 고전 검색보다 정답 문서를 찾을 가능성을 높이지만, 비용은 100~1,000배, 지연은 수분까지 늘 수 있다. 검색 전용 모델은 정답 문서 발견 여부와 지연 시간을 보상으로 두고 검색·읽기·필터·재검색을 반복한다. 제시된 초기 결과는 프런티어 모델의 약 2분 실행을 평균 5초로 줄이고 비용을 약 100배 낮췄지만, 고전 파이프라인의 밀리초 지연에는 아직 도달하지 않았다. 이 구조의 핵심은 평균 정확도 한 점이 아니라 질문 난도별 검색 횟수, 최종 문서 발견률, 지연과 비용의 곡선을 함께 기록하는 것이다.

4. 04

   검증 경계: 세 층을 한 벤치마크로 뭉개지 않는다

   멀티스케일 표현은 recall 손실을, 네임스페이스와 메모리 계층은 격리·P99·저장 비용을, RL 검색은 행동 예산과 문서 발견률을 겨냥한다. 평가도 이 경계를 보존해야 한다. 먼저 고정 청크와 멀티스케일의 recall@K를 비교하고, 다음으로 핫·콜드 부하와 규제 격리 조건에서 캐시 적중률과 왕복 수를 측정한 뒤, 마지막으로 동일 코퍼스에서 고정 파이프라인과 반복 검색의 성공률·지연·비용을 비교한다. 세 실험을 한 번에 바꾸면 어느 개선이 품질을 만들었는지 분리할 수 없다.

실무 순서는 표현, 저장, 행동 순으로 경계를 세우는 편이 안전하다. 질의군별로 필요한 해상도가 실제로 다른지 확인하고, 업무·관할권 단위 네임스페이스로 데이터 수명 주기와 격리를 맞춘 뒤, 남는 롱테일 실패에만 반복 검색 예산을 투입한다. 이때 멀티스케일의 저장 배수, 오브젝트 스토리지의 왕복, 전문 에이전트의 추가 계산을 모두 비용 모델에 넣어야 한다. 더 영리한 검색기 하나가 아니라 측정 가능한 세 층의 결합이 운영 가능한 검색 시스템을 만든다.