Databricks, 엔터프라이즈 검색 전용 RAG 에이전트 ‘KARL’ 공개

Databricks KARL 개요: 멀티태스크 RL로 재정의하는 엔터프라이즈 검색

Databricks는 강화학습 기반 RAG(검색증강생성) 에이전트 ‘KARL(Knowledge Agents via Reinforcement Learning)’을 공개했다. KARL은 여섯 가지 엔터프라이즈 검색 행동을 동시에 학습하도록 설계됐고, KARLBench라는 전용 벤치마크에서 Claude Opus 4.6에 필적하는 성능을 보였다는 것이 회사의 설명이다. 질의당 비용은 33% 낮고 지연은 47% 짧았으며, 모든 학습은 사람이 라벨링하지 않은 자체 합성 데이터로 이뤄졌다.

왜 기존 RAG가 한계에 부딪히는가

표준 RAG의 일반화 함정과 엔터프라이즈 검색 난제

대부분의 RAG 파이프라인은 하나의 검색 행동에 최적화되어 다른 유형에서는 조용히 실패한다. 예를 들어 문서 간 보고서 종합에 맞춘 모델은 제약 기반 엔터티 검색에 취약하고, 단순 조회에 특화된 모델은 내부 노트에 대한 다단계 추론에서 무너진다. Databricks는 이를 평가하기 위해 여섯 가지 행동(제약 기반 엔터티 검색, 문서 간 종합, 표·수치 추론을 포함한 장문 탐색, 포괄적 엔터티 검색, 기술 문서 절차 추론, 사내 노트 사실 집계)으로 구성된 KARLBench를 구축했다. 특히 Databricks의 제품 관리자 미팅 노트에서 만든 PMBench는 파편화·모호성·비정형성 탓에 최첨단 모델도 고전하는 사례다. 단일 작업만으로 학습한 모델은 다른 작업에서 성능이 급락했지만, 멀티태스크 강화학습은 보지 못한 작업으로 일반화됐다.

근거 중심 추론과 대규모 검색

“RAG+++”: 최대 200회 벡터 호출을 견인하는 추론 사슬

KARL은 검색으로 취득한 사실에 각 추론 단계를 고정(anchor)하는 ‘근거 중심 추론(grounded reasoning)’을 수행한다. 실제로 일부 과제에서는 최대 200회의 벡터 데이터베이스 질의를 연쇄적으로 실행하며, 검색을 정제하고 세부를 검증·교차 확인한 뒤 답을 확정한다. 별도의 요약 모델을 두지 않고, 강화학습만으로 컨텍스트가 과도해질 때 자가 압축하도록 학습시킨 결과, 압축을 제거하면 한 벤치마크 정확도가 57%에서 39%로 급락했다.

학습 엔진 OAPL: 왜 중요한가

오프폴리시 안정성, 높은 샘플 효율, 실용적 예산

KARL의 학습은 Cornell·Databricks·Harvard가 공동 개발한 OAPL(Optimal Advantage-based Policy Optimization with Lagged Inference)로 구동된다. 온폴리시 전제의 GRPO와 달리, OAPL은 분산 학습의 오프폴리시 특성을 정면 수용해 400회가 넘는 정책 지연에서도 안정적인 회귀 기반 목적함수로 학습을 지속한다. 코드 생성 실험에서는 GRPO 수준의 성능을 약 3배 적은 샘플로 달성했다. 이미 수집한 롤아웃을 재사용해 매 스텝 새 온폴리시 데이터를 요구하지 않으므로, 전체 학습을 수천 GPU 시간 내로 억제해 연구 단계를 넘어 실무 팀도 시도 가능한 예산으로 낮춘다.

에이전트 메모리와 컨텍스트 스택

벡터 DB–압축/캐싱–LLM 컨텍스트의 계층

산업계 일각에서는 RAG를 맥락적(에이전트형) 메모리로 대체할 수 있다는 논의가 있으나, KARL 팀은 이를 계층형 스택으로 본다. 수백만 항목의 벡터 데이터베이스가 바닥을 이루고, 꼭대기에 LLM 컨텍스트 윈도우가 놓이며, 그 사이를 압축과 캐싱이 메운다. KARL은 이 중간층을 RL로 끝단까지 학습해, 컨텍스트가 넘치면 스스로 요약·압축하고 작업을 이어간다.

KARL의 한계와 실패 양상

모호성 판단, 조기 중단, 기능 범위

KARL은 정답이 하나로 수렴하지 않는 모호한 질문에서 특히 어려움을 겪으며, 질문이 본질적으로 개방형인지 단순히 난해한지 가르는 판단은 여전히 미해결 문제다. 일부 질의에서 최종 답을 내기 전에 ‘일찍 멈춤’이 관측되지만, 비용이 큰 질의일수록 오답 가능성이 높다는 점에서 중단이 합리적일 때도 많다. 또한 현재 모델은 벡터 검색에 한해 학습·평가되었고, SQL 질의·파일 검색·Python 계산 등은 로드맵상 다음 단계다.

엔터프라이즈 데이터 팀을 위한 시사점

파이프라인 아키텍처 재설계

하나의 행동에만 최적화된 RAG는 다른 행동에서 실패한다. 다양한 검색 행동을 아우르는 멀티태스크 강화학습은 보지 못한 과제로 일반화하며, 협소한 파이프라인은 그렇지 못한다.

왜 강화학습인가: 전이 가능한 ‘검색 행동’의 습득

전문가 모델 증류(SFT)는 분포 내 성능은 올렸지만 미관측 작업에서는 개선이 거의 없었다. 반면 RL은 전이 가능한 일반적 검색 행동을 형성했다.

RL 효율성의 실무적 의미

잘 학습된 모델은 더 적은 단계로 과제를 끝내고, 답할 수 없는 질의는 더 일찍 멈추며, 실패한 쿼리를 반복하지 않고 탐색을 다양화하고, 스스로 컨텍스트를 압축해 자원 고갈을 피한다. 범용 API로 우회하기보다 목적형 에이전트를 훈련하는 주된 이유는 비용만이 아니라, 엔터프라이즈 검색 업무를 제대로 수행하는 능력 자체다. 결국 엔터프라이즈 검색 파이프라인을 멀티태스크 RL 기반으로 재구성하는 것이 장기적으로 경쟁력을 좌우한다.