Retrieval Router는 질문에 맞는 검색 소스를 자동으로 고르는 계층입니다. 단순히 검색을 한번 더 하는 장치가 아니라, 어떤 데이터셋을 우선할지와 어떤 검색 전략이 더 적합한지를 결정하는 게 핵심입니다.
이 방식은 내부 문서 중심 시스템과 웹 리서치 중심 시스템을 하나의 제품 안에서 같이 운영할 때 특히 유용합니다.
왜 중요한가 #
검색 소스가 늘어나면 오히려 정확도가 떨어질 수 있습니다. 검색 대상이 많아질수록 잘못된 소스를 먼저 고르는 비용이 커지기 때문입니다.
- 사내 문서와 외부 웹을 같은 우선순위로 두면 정책 위반이 생깁니다.
- 벡터 검색만 고집하면 최신 정보가 늦습니다.
- 검색 소스가 많을수록 라우터가 없으면 운영 규칙이 코드 곳곳에 퍼집니다.
라우팅/재작성 설계 #
라우터는 보통 아래 순서로 움직입니다.
- 질문의 의도와 최신성 요구를 분류합니다.
- 내부 문서, 외부 웹, 통합 검색 중 하나를 선택합니다.
- 필요한 경우 질문을 재작성해서 검색 효율을 높입니다.
- 검색 결과를 합치고 reranking을 적용합니다.
|
|
실무에서는 다음 규칙이 잘 먹힙니다.
- 정책, 가격, API 문서처럼 변화가 빠른 항목은 웹 검색을 우선합니다.
- 제품, 운영, 내부 지식은
Hybrid Search를 우선합니다. - 소스가 애매하면
Retrieval Quality Metrics로 라우터 성능을 따로 봅니다.
아키텍처 도식 #
라우터는 검색 백엔드 앞단에서만 동작시키지 말고, 결과 품질 로그도 같이 남겨야 합니다. 그래야 어떤 소스가 자주 오판하는지 보입니다.
- router decision을 샘플링해서 검토합니다.
- source별 latency와 hit rate를 분리해서 봅니다.
- failover를 명시적으로 둡니다.
체크리스트 #
- 질문마다 우선 검색 소스를 한 번만 정하고 있는가
- 내부/외부/혼합 검색 기준이 문서화되어 있는가
- 라우터의 오판을 추적할 수 있는가
- 소스별 비용과 latency를 따로 볼 수 있는가
- reranking과 query rewriting의 적용 순서를 정했는가
결론 #
Retrieval Router는 검색 품질을 자동화하는 계층입니다. 검색 소스가 늘어나는 순간부터는 “어디서 검색할지"가 “무엇을 검색할지"만큼 중요해집니다.
처음에는 단순 규칙 기반으로 시작하고, 이후에 query classifier와 재작성 단계를 붙이는 방식이 가장 안전합니다.