🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Google Research와 Google Cloud는 복잡한 기업 질의를 여러 단계로 분해하고, 충분한 근거가 모일 때까지 반복 검색하는 Gemini Enterprise Agent Platform의 agentic RAG 프레임워크를 공개했다.

📌 핵심 요약

• 기존 단일 단계 RAG는 여러 데이터 소스와 여러 추론 단계를 거쳐야 하는 기업 업무 질의에 취약하며, 정보가 분산되어 있을 때 부분 답변이나 ‘찾을 수 없음’ 응답으로 끝날 수 있다.
• Google의 agentic RAG는 오케스트레이터, 플래너, 쿼리 리라이터, 검색 팬아웃, RAG 에이전트, 충분한 컨텍스트 에이전트, 합성 에이전트가 역할을 나눠 질의를 처리한다.
• 핵심 차별점은 첫 검색 결과만으로 답하지 않고, 충분한 정보가 있는지 평가한 뒤 누락된 항목을 특정해 다시 검색하도록 만드는 ‘Sufficient Context Agent’에 있다.
• 의료 예시에서는 퇴원 약물, 식이 제한, 알레르기 반응이라는 세 가지 요구를 확인하고, 알레르기 정보가 없으면 ‘rash’나 ‘adverse events’ 같은 새로운 검색을 유도해 빠진 근거를 찾는다.
• FramesQA 실험에서 이 방식은 표준 RAG보다 사실성 데이터셋 정확도를 최대 34% 높였고, 4개 코퍼스 중 올바른 자료원을 골라야 하는 cross-corpus 조건에서도 90.1% 정답률을 달성했다.

🧩 주요 포인트

1. 기존 단일 단계 RAG는 여러 데이터 소스와 여러 추론 단계를 거쳐야 하는 기업 업무 질의에 취약하며, 정보가 분산되어 있을 때 부분 답변이나 ‘찾을 수 없음’ 응답으로 끝날 수 있다.
2. Google의 agentic RAG는 오케스트레이터, 플래너, 쿼리 리라이터, 검색 팬아웃, RAG 에이전트, 충분한 컨텍스트 에이전트, 합성 에이전트가 역할을 나눠 질의를 처리한다.
3. 핵심 차별점은 첫 검색 결과만으로 답하지 않고, 충분한 정보가 있는지 평가한 뒤 누락된 항목을 특정해 다시 검색하도록 만드는 ‘Sufficient Context Agent’에 있다.
4. 의료 예시에서는 퇴원 약물, 식이 제한, 알레르기 반응이라는 세 가지 요구를 확인하고, 알레르기 정보가 없으면 ‘rash’나 ‘adverse events’ 같은 새로운 검색을 유도해 빠진 근거를 찾는다.
5. FramesQA 실험에서 이 방식은 표준 RAG보다 사실성 데이터셋 정확도를 최대 34% 높였고, 4개 코퍼스 중 올바른 자료원을 골라야 하는 cross-corpus 조건에서도 90.1% 정답률을 달성했다.

🧠 상세 정리

1. 기존 RAG의 한계와 문제의식

글은 현재의 단일 단계 검색 증강 생성, 즉 표준 RAG가 현대 기업 업무의 복잡한 질의를 처리하도록 설계되지 않았다는 문제에서 출발한다. 예를 들어 사용자가 ‘Project X에 쓰인 서버의 사양’을 묻는 경우, 시스템은 Project X 문서를 찾을 수는 있지만 그 문서에 서버 ID만 적혀 있다면 다음 데이터베이스에서 사양을 다시 찾는 과정을 수행하지 못할 수 있다. 정보가 서로 다른 데이터 ‘섬’에 흩어져 있으면 단순 검색은 필요한 사실을 끝까지 추적하지 못하고, 결과적으로 부분 답변이나 ‘찾을 수 없음’ 응답을 내놓게 된다. 이 글은 이러한 다중 소스, 다중 홉 질의가 기업 환경에서 점점 중요해졌기 때문에 더 깊은 탐색과 추론이 필요하다고 설명한다.

2. Google의 agentic RAG 프레임워크 소개

Google Research와 Google Cloud의 협업으로 소개된 새 agentic RAG 프레임워크는 복잡한 기업 질의를 분해하고, 충분한 문맥을 찾을 때까지 반복적으로 데이터 소스를 검색하는 다중 에이전트 워크플로다. 이 기능은 Gemini Enterprise Agent Platform에 호스팅된 Cross-Corpus Retrieval powered by Agentic RAG 형태로 공개되었다. 글은 이 접근이 다른 다중 에이전트 RAG와 마찬가지로 여러 에이전트가 협력해 복잡한 질문에 답하지만, 특히 정확한 답변에 충분한 정보가 있는지 확인하는 절차를 포함한다는 점을 강조한다. 표준 RAG와 비교해 사실성 데이터셋에서 정확도를 최대 34% 높였고, 내부 독점 데이터셋 평가에서도 더 나은 grounding과 도메인 특화 과제의 추론 정확도 향상을 확인했다고 설명한다.

3. 다중 에이전트 구조의 기본 역할

글은 다중 에이전트 RAG를 하나의 검색 엔진이 아니라 조직화된 연구 부서에 비유한다. 단일한 ‘Vanilla’ RAG에서는 검색 구성요소가 질문과 맞는 문서를 찾고, 이후 LLM이 응답을 생성하는 방식으로 동작한다. 반면 다중 에이전트 구조에서는 오케스트레이터가 사용자의 복잡한 요청을 평가해 한 단계 작업이 아니라고 판단하고, 다른 에이전트들에게 일을 나눠 맡긴다. 플래너 에이전트는 예산과 일정처럼 서로 다른 정보 경로가 필요한 질문에서 어떤 데이터베이스와 로그를 먼저 확인할지 계획한다. 쿼리 리라이터는 모호한 질문을 여러 개의 구체적인 검색문으로 바꾸고, 검색 팬아웃 에이전트는 이 검색문을 여러 검색 소스에 보내 필요한 정보 조각을 수집한다.

4. 차별점으로 제시된 지속성

Google이 강조하는 핵심 차이는 ‘persistence’, 즉 충분한 정보를 얻을 때까지 계속 탐색하는 지속성이다. 이 프레임워크는 첫 검색에서 답이 비어 있거나 일부만 발견되었을 때 곧바로 추측하거나 단순히 정보가 부족하다고 말하는 데서 멈추지 않는다. 대신 현재 검색 결과가 원래 질문을 충족하는지 판단하고, 빠진 항목이 있으면 다시 검색하도록 흐름을 되돌린다. 글은 물론 어떤 경우에는 정보가 부족하다고 답하는 것이 적절할 수 있지만, 실제로는 정보가 존재하는데 아직 찾지 못한 상황도 많다고 본다. 따라서 agentic RAG의 가치는 단순히 검색을 많이 하는 것이 아니라, 무엇이 빠졌는지를 인식하고 그 빈틈을 겨냥해 탐색을 이어가는 데 있다.

5. 의료 질의 예시와 단계별 처리

글은 의사가 환자 John Doe의 무릎 수술 후 퇴원 약물, 식이 제한, 입원 중 알레르기 반응 여부를 묻는 예시로 시스템 동작을 설명한다. 1단계에서 Root Agent는 의사의 긴 요청을 파싱하고, Planner Agent는 약국, 영양, 임상 노트라는 세 영역을 확인해야 한다고 식별한다. Query Rewriter는 긴 질문을 검색 가능한 간단한 질문들로 나눠 retriever가 관련 내용을 더 정확히 찾도록 한다. 2단계에서 RAG Agent는 모든 query fanout을 한 번에 검색해 약물과 식이 정보는 찾지만, 가장 obvious한 파일에서는 알레르기 언급을 찾지 못한다. 표준 RAG라면 여기서 불완전한 답변으로 끝날 수 있지만, 이 프레임워크는 이후 충분성 평가와 반복 검색으로 넘어간다.

6. Sufficient Context Agent의 검증 방식

Sufficient Context Agent는 글에서 조립 라인 끝의 품질 관리 검사관에 비유된다. 이 에이전트는 데이터베이스에서 검색된 실제 텍스트 조각, 시스템이 만든 중간 초안, 그리고 누락 요소 분석이라는 세 가지를 검토한다. 예컨대 의사의 질문에서 검색 조각이 퇴원 요약과 영양 노트의 문단이라면, 해당 문장들이 약물, 식이, 알레르기라는 질문의 모든 요소를 답할 수 있는지 읽어 본다. 또한 프롬프트, 초안, 검색 조각을 함께 검토해 모델이 포괄적이고 근거 있는 답변을 만들 수 있는지 평가한다. 정보가 두 항목에만 있고 세 번째 항목이 빠졌다면 ‘insufficient context’로 표시하고, 무엇이 부족한지 이유와 피드백 로그를 구체적으로 생성한다.

7. 반복 검색과 최종 합성

충분한 컨텍스트가 없다고 판단되면 Sufficient Context Agent는 단순히 실패를 선언하지 않고 구체적인 후속 검색 방향을 제시한다. 의료 예시에서는 약물 목록과 저염식 지침은 찾았지만 입원 중 알레르기 반응이나 부작용 관련 문서 정보가 없다는 식으로 누락 지점을 명확히 한다. 이어 ‘rashes’나 ‘adverse events’를 구체적으로 검색하라는 피드백을 제공하고, Query Rewriter는 이 피드백을 바탕으로 새로운 검색을 만든다. RAG Agent는 처음에는 지나쳤던 파일을 더 깊이 탐색해 빠진 정보를 찾는다. 마지막으로 Sufficient Context Agent가 약물, 식이, 알레르기 정보가 모두 확보되었는지 다시 확인한 뒤 검색을 중단하고, Synthesis Agent가 의사를 위한 깔끔하고 정확한 요약 답변을 작성한다.

8. FramesQA 실험과 다중 홉 질의 평가

실험 부분에서는 FRAMES 논문에 기반한 FramesQA를 사용해 agentic RAG를 평가했다고 설명한다. 예시 질문은 2024년 6월 기준 가장 많이 시청된 텔레비전 시즌 피날레 상위 두 개 중 어느 피날레가 더 길었고 얼마나 차이 나는지를 묻는 다중 홉 질문이다. 올바르게 답하려면 먼저 상위 두 피날레가 MASH와 Cheers임을 식별하고, 이어 각각의 방영 시간을 찾은 뒤, 길이 차이를 계산해야 한다. Vanilla RAG나 충분한 컨텍스트 없는 agentic RAG에서는 시청률 자료만 찾고 러닝타임을 찾지 못해 질문에 답하지 못할 수 있다. Google의 agentic RAG는 먼저 TV 프로그램을 찾고, Query Rewriter와 Sufficient Context Agent를 통해 MASH와 Cheers의 러닝타임을 겨냥해 다시 검색한 뒤, MAS*H가 150분으로 Cheers의 약 98분보다 52분 길었다는 답을 도출한다.

9. 단일 코퍼스와 cross-corpus 결과

FramesQA는 824개의 질의와 2,676개의 PDF 문서 코퍼스를 포함하며, 글은 이를 사용해 규모 있는 실험을 수행했다고 밝힌다. Vanilla RAG 조건에서는 고급 검색 엔진, LLM parser, re-ranker를 갖춘 Google의 RAG Engine을 사용했고, 이를 agentic RAG의 두 설정과 비교했다. 단일 코퍼스 설정에서는 FramesQA 문서에서만 검색하고, cross-corpus 설정에서는 세 개의 방해 데이터셋을 추가해 Planner Agent가 어느 코퍼스에서 검색해야 하는지 선택해야 한다. 이 cross-corpus 조건은 회사 내부 데이터베이스가 여러 팀에 의해 분리 관리되는 실제 기업 사용 사례를 모방한다. 결과적으로 cross-corpus 설정에서도 단일 코퍼스 정확도에 거의 근접했고, 네 가지 가능성 중 올바른 코퍼스를 골라야 하는 상황에서도 90.1%의 질문에 올바르게 답했으며, 두 설정의 지연 시간도 평균 3% 이내로 비슷했다고 설명한다.

10. 결론과 공개 미리보기

글의 결론은 고급 질의 계획, 라우팅, 충분한 컨텍스트 검증을 결합하면 AI가 생성하는 응답을 감사 가능하고 추적 가능하며 근거 있는 형태로 만들 수 있다는 주장으로 정리된다. agentic RAG는 단순히 더 많은 문서를 검색하는 시스템이 아니라, 답변에 필요한 증거가 충분한지 판단하고 부족한 부분을 다시 찾도록 설계된 구조다. 특히 여러 관련 없는 데이터 소스에 걸쳐 추론할 수 있다는 점은 기업 환경에서 더 유연한 검색 시나리오를 가능하게 한다고 글은 평가한다. 이 기능은 Gemini Enterprise Agent Platform에서 public preview offering으로 제공된다고 안내된다. 마지막에는 프로젝트 참여자와 그래픽, 글쓰기 지원, 기업 파트너들의 피드백과 데이터, 인사이트에 대한 감사가 덧붙어 있다.

🧾 핵심 주장 / 시사점

• 이 글의 핵심은 RAG의 성능을 단순 검색 품질이 아니라 ‘언제 답하지 말고 더 찾아야 하는지’를 판단하는 제어 구조의 문제로 재정의한 데 있다.
• Sufficient Context Agent는 hallucination을 줄이는 장치인 동시에, 어떤 근거가 있고 어떤 근거가 없는지 로그로 남기는 감사 가능성의 기반으로 제시된다.
• cross-corpus 실험 결과는 기업 데이터가 부서별·시스템별로 분리되어 있을 때, 올바른 자료원 선택과 반복 검색이 RAG 실용성의 중요한 병목임을 보여준다.

✅ 액션 아이템

• Agentic RAG를 도입할 때 Planner Agent, Query Fan-out, Iterative Retrieval, Sufficient Context Agent가 각각 어떤 실패 모드를 줄이는지 현재 RAG 파이프라인에 매핑한다.
• cross-corpus retrieval 실험에서 나타난 3%, 34%, 90.1% 같은 수치가 retrieval 품질, 답변 충분성 판단, hallucination 감소 중 어느 지표와 연결되는지 분리해 검토한다.
• 기업 데이터가 여러 corpus에 흩어진 환경에서는 단일 vector search보다 corpus 선택, 반복 검색, 근거 부족 감지를 로그로 남기는 audit trail을 우선 설계한다.

❓ 열린 질문

• Planner Agent가 검색 계획을 세우는 구조는 기존 keyword/vector hybrid search보다 어떤 enterprise 질의에서 가장 큰 차이를 만들까?
• Sufficient Context Agent가 “근거가 충분하지 않다”고 판단하는 기준을 운영 환경에서 어떻게 측정하고 조정해야 할까?
• cross-corpus RAG가 부서별 데이터 사일로를 넘나들 때 권한, 감사 로그, 근거 출처 표시를 어디까지 사용자에게 노출해야 할까?