기업용 AI 챗봇의 품질은 생성 모델의 크기만으로 결정되지 않습니다. 실제 병목은 사용자의 질문에 맞는 문서를 얼마나 빠르고 정확하게 찾느냐에 있는 경우가 많습니다.
Databricks의 Instructed-Retriever-1은 이 병목을 겨냥한 검색 특화 모델입니다. Databricks Knowledge Assistant는 문서 기반 질의응답 챗봇을 만들고 답변에 인용을 제공하는 기능인데, 전통적 RAG의 한계를 보완하기 위해 Instructed Retriever 접근 방식을 사용합니다.1
Instructed-Retriever-1은 무엇을 바꾸나
일반적인 RAG는 사용자 질문과 의미적으로 가까운 문서를 찾고, 그 결과를 LLM에 넘기는 방식으로 작동합니다. 이 접근은 단순한 질의에는 효과적이지만, 기업 문서 검색에서는 한계가 드러납니다.
예를 들어 사용자가 “최근 정책 문서만”, “특정 제품군은 제외”, “공식 문서 우선”처럼 조건이 포함된 질문을 할 수 있습니다. 이때 검색 단계가 사용자의 지시를 충분히 이해하지 못하면, 생성 모델이 아무리 좋아도 답변 품질은 흔들립니다.
Instructed-Retriever-1은 이 문제를 검색 단계에서 다룹니다. 사용자 지시와 인덱스 스키마를 바탕으로 검색 쿼리를 만들고, 가져온 후보 문서를 다시 정렬합니다. 특히 쿼리 생성과 재랭킹을 별도 구성 요소가 아니라 하나의 검색 특화 모델이 모두 수행하도록 설계됐다는 점이 핵심입니다.2
속도의 핵심은 병렬화다
표준 에이전트형 검색은 결과를 검토한 뒤 다음 행동을 결정하는 순차적 방식에 가깝습니다. 이런 방식은 더 정교한 탐색을 가능하게 하지만, 단계가 늘어날수록 지연 시간도 커집니다.
Instructed-Retriever-1은 다른 방향을 택합니다. 초기 검색 단계의 작업을 병렬로 확장해 여러 가능성을 동시에 탐색합니다. Databricks는 이를 Parallel Test-Time Scaling이라고 설명합니다.2
적용 결과는 속도 개선으로 제시됐습니다. Knowledge Assistant에 Instructed-Retriever-1을 적용한 뒤 검색 시간은 3배 이상 단축됐고, 답변 생성 시간은 2배 줄었으며, Time To First Token은 약 2초로 제시됐습니다.2
좋은 RAG를 판단하는 기준
Instructed-Retriever-1이 보여주는 메시지는 “더 큰 LLM을 쓰면 된다”가 아닙니다. 기업용 질의응답에서는 생성 모델만큼이나 검색 설계가 중요합니다.
특히 다음과 같은 질문을 던져볼 필요가 있습니다.
검색 단계가 사용자의 지시를 이해하는가?
문서의 메타데이터와 구조를 검색에 활용하는가?
후보 문서를 단순히 가져오는 데 그치지 않고 재정렬하는가?
품질 개선이 응답 지연 증가로 이어지지 않는가?
Databricks는 Instructed-Retriever-1이 KARLBench에서 Claude Sonnet 4.5 수준의 검색 품질을 보이면서도 낮은 지연 시간을 유지한다고 설명합니다.2 중요한 점은 고성능 생성 모델을 대체한다는 의미가 아니라, 검색 전용 모델을 통해 RAG 파이프라인의 병목을 줄인다는 데 있습니다.
결론: 프롬프트보다 먼저 검색을 점검하라
RAG 기반 챗봇의 품질을 높이고 싶다면 프롬프트나 생성 모델만 볼 것이 아니라, 검색 단계가 어떻게 설계됐는지 먼저 점검해야 합니다.
Instructed-Retriever-1의 의미는 단순히 더 빠른 검색 모델이 나왔다는 데 있지 않습니다. 사용자 지시를 이해하고, 검색과 재랭킹을 통합하며, 병렬화로 지연 시간을 줄이는 방식으로 기업용 RAG의 검색 구조를 다시 설계했다는 점에 있습니다.
1Use Knowledge Assistant to create a high-quality chatbot over your documents
23x Faster Search: Parallel Test-Time Scaling with Instructed-Retriever-1
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.