- 에이전트 AI
Agentic RAG는 AI 에이전트가 검색 프로세스를 제어하는 검색 증강 생성의 한 형태입니다. 표준 RAG의 고정된 일회성 검색 후 생성 파이프라인을 따르는 대신 에이전트는 검색 시기, 쿼리할 도구 또는 소스, 결과가 응답하기에 충분한지 여부를 결정합니다. 충분한 기반 컨텍스트가 있거나 정의된 중지 지점에 도달할 때까지 반복됩니다.
표준 RAG범위가 지정된 말뭉치에 대한 간단한 프롬프트에는 잘 작동하지만 답변이 여러 단계에 의존하거나 여러 소스에 걸쳐 있거나 응답하기 전에 증거 검증이 필요한 경우에는 작동하지 않습니다. 결과적으로 답변은 불완전하거나 검증할 수 없거나 단순히 잘못된 답변이 됩니다. 더 나은 답변을 제공하기 위해 격차를 메워주는 에이전트 RAG가 더 나은 선택입니다.
이 블로그 게시물에서는 에이전트 RAG의 작동 방식, 가장 적합한 위치, 적용되는 아키텍처 패턴에 대해 설명합니다. 또한 얻을 수 있는 것과 절충할 점, 이를 구현하고 평가하는 방법, GraphRAG가 강력한 검색 기반을 제공하는 이유에 대해서도 살펴보겠습니다.
이 가이드의 추가 정보:
- 에이전트 RAG는 어떻게 작동하나요?
- 기존 RAG 대 에이전트 RAG: 언제 어느 것을 사용해야 합니까?
-
- 반응 RAG
-
- 라우터 RAG
-
- 교정 RAG
-
- 적응형 RAG
-
- 다중 에이전트 RAG
-
-
- 1. 표준 RAG 기준선 설정
-
- 2. 먼저 실패 모드를 식별하십시오.
-
- 3. 도움이 되는 에이전트 패턴을 도입하세요.
-
- 4. 루프 반복에 대한 최대 제한 설정
-
- 5. 상황 최적화
-
- 6. 확장 전 계측
-
-
- 답변 품질 지표
-
- 시스템 수준 측정항목
-
- 에이전트 GraphRAG에 대한 지식 그래프
- Agentic RAG FAQ
에이전트 RAG는 어떻게 작동하나요?
Agentic RAG는 다음으로 시작합니다.AI 에이전트사용자의 질문을 이해하고 이에 대답하는 방법을 추론합니다. 표준 RAG와 달리 에이전트 RAG에는 계획, 도구 선택, 생성 전 여러 차례의 검색 및 평가가 포함됩니다. 이런 일을 겪는다에이전트 워크플로좋은 답변을 제공하기에 충분한 컨텍스트가 있을 때까지 루프를 반복합니다.
상담원이 응답하기 전에 증거를 조사하고 필요한 경우 경로를 수정하는 데 시간을 투자하기 때문에 답변의 신뢰성이 더 높습니다. 또한 검색 경로, 도구 사용 및 지원 컨텍스트를 노출하여 답변을 더 쉽게 감사하고 설명할 수 있습니다.
기존 RAG 대 에이전트 RAG: 언제 어느 것을 사용해야 합니까?
모든 작업에 에이전트 루프가 필요하지 않습니다. 질문이 간단하고 하나의 검색 패스로 답변할 수 있는 경우 표준 RAG로 시작하세요. Agentic RAG로 전환하여 복잡한 질문에 답하세요.다단계 추론, 라우팅 또는 유효성 검사를 받은 후 응답하세요.
그러나 Agentic RAG에는 실제 비용이 발생합니다. 토큰 사용량이 늘어납니다. 각 루프, 검색 단계 및 유효성 검사 단계에 따라 지연 시간이 늘어납니다. 실패는 계획 및 검색부터 도구 사용, 조정 또는 중지 논리까지 모든 단계에서 표면화될 수 있습니다. 반영과 반복은 특정 격차를 목표로 삼을 때만 결과를 향상시킵니다. 그렇지 않으면 비용만 추가됩니다.
다음 표는 표준 RAG와 에이전트 RAG의 기본 사항에 대한 스냅샷을 제공합니다.
| 표준 RAG | 에이전트 RAG | |
| 가장 효과적인 용도 | 범위가 지정된 코퍼스에 대한 간단한 기반 정보 검색 | 다단계 추론, 소스 간 합성, 검증이 많은 작업 |
| 작업 흐름 | 일회성 검색 후 생성 흐름(때로는 순위 재지정 또는 쿼리 재작성으로 개선됨) | 계획, 검색, 평가 및 중지 규칙이 포함된 적응형 루프 |
| 속도와 비용 | 토큰 사용 감소 및 대기 시간 감소 | 토큰 사용량이 많고 쿼리당 대기 시간이 길어집니다. |
| 신뢰성 및 실패 표면 | 디버깅이 더 쉽습니다. 오류는 검색이나 생성 시에만 발생할 수 있습니다. | 계획, 검색, 도구 사용, 검증, 조정 또는 생성의 여러 단계에서 오류가 발생할 수 있습니다. |
| 검색 전략 | 대개 하나의 기본 검색 경로 | 도구, 검색기, 그래프 쿼리 및 여러 소스에 걸쳐 라우팅할 수 있습니다. |
일반적인 에이전트 RAG 디자인 패턴
가장 일반적인 에이전트 RAG 설계 패턴은 간단한 추론 루프에서 다중 에이전트 조정까지 확장됩니다. 눈앞에 있는 특정 검색 또는 품질 문제를 해결하는 가장 간단한 패턴부터 시작하세요. 복잡성은 수정되는 오류의 이름을 명확하게 지정할 수 있는 경우에만 추가할 가치가 있습니다. 더 나은 아키텍처 결정은 일반적으로 긴 에이전트 루프보다 더 중요합니다.
반응 RAG
사용 시기:ReAct(Reasoning + Acting)는 가장 기본적인 에이전트 RAG 패턴입니다. 대부분의 표준 RAG 문제를 해결하므로 라우터, 유효성 검사기 또는 추가 에이전트를 계층화하기로 결정하기 전에 대부분의 구현에 대한 올바른 시작점이 됩니다.
작동 방식:에이전트는 세 단계를 순환합니다. "생각"(아직 필요한 정보에 대한 추론)을 생성하고 "작업"(검색 도구 호출: 벡터 검색, 키워드 검색, 문서 조회)을 수행하고 다음 추론 단계를 제공하는 "관찰"(검색 결과)을 수신합니다. 에이전트가 충분한 답변을 제공할 만큼 충분한 기반 컨텍스트를 갖거나 정의된 중지 지점에 도달할 때까지 루프가 계속됩니다.
라우터 RAG
사용 시기:단일 검색 방법으로는 모든 쿼리를 제대로 처리할 수 없을 정도로 쿼리가 다양할 때 이 라우터 설정을 사용하세요. 이는 시스템이 모든 요청에 대해 모든 소스를 쿼리하는 것을 방지합니다.
작동 방식:라우팅 단계는 생성이 시작되기 전에 각 쿼리를 가장 관련성이 높은 검색 방법이나 데이터 소스로 보냅니다. 예를 들어 의미론적 유사성을 위한 벡터 RAG, 연결된 엔터티 컨텍스트를 위한 GraphRAG, 더 간단한 조회를 위한 키워드, 데이터베이스 또는 웹 검색이 있습니다. 라우팅 결정은 일반적으로 라우터 에이전트에 의해 이루어집니다. 예를 들어, Neo4j의Python 패키지용 GraphRAG포함도구검색기, 쿼리와 일치하는 검색 도구를 선택하고 실행합니다.
교정 RAG
사용 시기:기본 인덱스에 적용 범위 격차가 있고 안정적인 대체 경로가 필요한 경우 이 수정 설정을 사용하세요.
작동 방식:검색 후 즉시 평가 단계가 실행됩니다. 검색된 컨텍스트가 관련되면 생성이 진행됩니다. 관련성이 없거나 모호한 경우 에이전트는 LLM에 컨텍스트를 전달하기 전에 대체 소스(일반적으로 웹 검색)로 대체됩니다. ReAct와의 주요 차이점은 수정이 발생하는 위치입니다. 수정 RAG는 동일한 검색을 다시 쿼리하는 대신 검색이 부족할 때 소스를 전환합니다.
적응형 RAG
사용 시기:혼합 쿼리 트래픽(전체 에이전트 파이프라인이 필요한 트래픽에 대한 단순 조회 범위)에 적응형 RAG 패턴을 사용하면 모든 요청에 대한 에이전트 루프의 전체 대기 시간과 비용을 방지할 수 있습니다.
작동 방식:적응형 RAG는 검색이 시작되기 전에 쿼리 복잡성 분류자를 추가합니다. 예를 들어 모델의 내부 지식을 사용하여 정확하게 대답할 수 있는 간단한 질문의 경우 에이전트 루프를 건너뛰고 바로 LLM으로 이동합니다. 단일한 사실적 답변이 있는 중간 정도의 질문은 단일 검색 단계를 거칩니다. 답변에 여러 단계의 추론 또는 소스 간 증거가 필요한 복잡한 질문은 평가 및 재검색을 통해 전체 에이전트 루프로 라우팅됩니다.
다중 에이전트 RAG
사용 시기:다중 에이전트 RAG 패턴은 단일 에이전트가 범위를 처리할 수 없는 경우에만 사용하십시오. 예를 들어 작업이 여러 도메인에 걸쳐 있거나 병렬 검색의 이점을 누리는 경우입니다. 작업을 분할하면 품질이나 처리량이 향상될 수 있지만 대기 시간, 비용 및 조정 오버헤드가 빠르게 증가하고 에이전트 경계를 넘어 오류를 추적하기가 더 어렵습니다.
작동 방식:다중 에이전트 설정은 전문 에이전트 간에 작업을 분할합니다. 한 에이전트는 계획을 처리하고 다른 에이전트는 컨텍스트 검색, 결과 검증 또는 최종 응답 준비에 중점을 둡니다.
일반적인 다중 에이전트 RAG 패턴에는 쿼리를 수신하고 계획 에이전트에 위임한 후 병렬 검색 에이전트를 파견하는 오케스트레이터 에이전트가 있습니다. 합성 에이전트는 결과를 결합하고, 검증 에이전트는 결합된 컨텍스트가 품질 기준을 충족하는지 확인하며, 생성 에이전트는 최종 응답을 생성합니다. 유효성 검사 단계가 실패하면 루프를 종료하는 대신 제어가 오케스트레이터로 반환됩니다.
에이전트 RAG의 사용 사례는 무엇입니까?
단일 검색 패스가 지속적으로 부족한 산업에서 에이전트 RAG가 작동하는 방법은 다음과 같습니다.
기업 지식
기업 관련 질문은 정책, 티켓 기록, 내부 문서, 시스템 데이터 전반에 걸쳐 이루어지는 경우가 많으며 충돌이 빠르게 나타납니다. 어려운 부분은 동의하지 않을 때 어느 출처를 신뢰할지 아는 것입니다. 정책 문서에는 한 가지 내용이 있고 지난달 전체 프레젠테이션에서는 다른 내용이 나와 있으며 내부 위키는 1년 넘게 업데이트되지 않았습니다. 검색 파이프라인은 모든 것을 반환합니다. 에이전트는 소스를 비교하고, 추론하고, 우선 순위를 결정하고, 확실한 승자가 없는 경우 불일치를 명시적으로 표시하여 충돌을 해결합니다.
재원
사기 조사결정론적 검색 경로를 따르지 않습니다. 플래그가 지정된 거래에 익숙하지 않은 상대방이 나타난다고 가정해 보겠습니다. 거래 자체가 의심스러운지 판단하기 전에 상대방이 누구인지 알아야 하므로 다음으로 끌어올 것은 더 많은 거래 내역이 아닌 상대방의 KYC 파일입니다. 해당 파일이 제재 대상 법인과 연결되어 있으면 문제는 사기에서 제재로 바뀌고 정책 문서는 대기열의 노출 분석보다 앞서게 됩니다. 표준 RAG는 이러한 일련의 추론을 표현할 수 없지만 에이전트 설정은 가능합니다. 방금 발견한 내용을 기반으로 다음에 수행할 작업을 결정하고 증거가 사례를 뒷받침하거나 배제할 만큼 강력할 때 중지할 수 있습니다.
합법적인
계약 검토는 순차적 검색 및 평가가 중요한 위치를 보여주는 좋은 예입니다. 무제한 책임 조항이 있고 일치하는 보험 조항이 없는 모든 계약을 찾는 것은 원패스 문제가 아닙니다. 하나의 검색 패스는 유사한 언어로 계약서를 반환합니다. 그렇다고 해서 올바른 계약을 찾았거나, 올바른 조항을 확인했거나, 두 조건을 함께 확인했다는 의미는 아닙니다. 에이전트는 문제를 순차적으로 해결합니다. 즉, 관련 계약을 식별하고, 조항 수준 콘텐츠를 검색하고, 보험 조건을 확인합니다. 다른 에이전트는 발견 항목을 평가하고 세 가지 검사가 모두 통과된 경우에만 응답을 생성합니다. 규정 준수 작업, 실사, 규제 검토 전반에 걸쳐 동일한 순차적 종속성이 나타납니다.
헬스케어
임상 결정은 상호의존적입니다. 환자의 병력이나 약물 상호작용을 평가하지 않고는 환자가 어떤 약물을 복용해야 하는지 추천할 수 없습니다. 각 검색 단계는 이전 단계의 결과에 따라 달라집니다. 표준 RAG는 큰 그림을 놓치는 경우가 많습니다. 에이전트 RAG는 먼저 환자 컨텍스트를 검색하고 이를 사용하여 다음에 검색할 항목을 결정합니다. 의료와 같이 위험이 높은 환경에서는 에이전트가 출력을 제공하기 전에 오류를 포착하는 데 검증 루프가 중요합니다.
고객 지원
고객 지원에는 제품 문서, 계정 데이터, 주문 내역, 오픈 티켓 등 다양한 소스의 데이터가 필요합니다. 그러나 어느 것, 어떤 순서인지는 질문에 따라 다릅니다. 청구 문제는 기술적인 문제와 다른 검색이 필요합니다. 라우터 에이전트는 모든 요청에 대해 모든 소스를 쿼리하지 않고 요청을 적절한 소스로 라우팅합니다.
에이전트 RAG 구현 방법
에이전트 RAG를 표준 RAG에 대한 업그레이드로 취급하십시오. 표준 기준으로 시작한 다음 에이전트 RAG 패턴을 추가하거나 현재 파이프라인이 부족한 부분을 점진적으로 최적화합니다. 작은 변화를 통해 각각의 이득을 더 쉽게 평가하고 제자리를 얻지 못하는 복잡성을 줄일 수 있습니다.
1. 표준 RAG 기준선 설정
데이터 저장소, 검색기, LLM 등 간단한 RAG 파이프라인으로 시작하세요. 에이전트 루프를 추가하기 전에 벡터 검색을 기준으로 사용하고 답변 품질, 대기 시간 및 빈 컨텍스트 비율을 측정하세요. 이 숫자는 이후의 모든 변경 사항을 측정하는 기준이 됩니다.
2. 먼저 실패 모드를 식별하십시오.
무슨 일이 일어나고 있나요? 아키텍처를 변경하기 전에 구체적인 오류의 이름을 지정하세요. 소스 간 라우팅 불량, 멀티 홉 컨텍스트 누락, 설명 가능성 부족, 확인이 필요한 답변에는 모두 다양한 수정이 필요합니다. 한 번에 모든 문제를 해결하려고 하면 각 문제를 추적하기가 더 어려워집니다.
3. 도움이 되는 에이전트 패턴을 도입하세요.
실패의 이름을 지정한 후에는 어떤 패턴이 격차를 줄일 수 있는지 고려하세요. 가장 자주 실패하는 단계에 검토 단계를 추가합니다. ReAct 루프는 일반적인 시작점입니다. 명시적인 통과/실패 기준을 미리 정의합니다(예: 최소 충실도 점수 또는 필수 엔터티 일치). 여전히 필요한 답변을 제공하지 못하는 경우 라우터, 교정 또는 적응 패턴과 같은 에이전트 루프에 레이어를 추가하거나 작업량이 많거나 많은 컨텍스트를 소비하는 작업을 위한 특수 에이전트를 추가하는 것을 고려해 보십시오.
4. 루프 반복에 대한 최대 제한 설정
시스템이 비용이 많이 들고 추적하기 어려운 재시도를 방지하기 위해 루프 반복에 하드 캡을 중지 기준으로 설정합니다. 이는 에이전트 RAG에서 가장 어려운 튜닝 문제 중 하나입니다. 너무 엄격하면 충분한 컨텍스트가 확보되기 전에 루프가 종료됩니다. 너무 느슨하면 답변을 개선하지 않고도 비용이 추가됩니다.
5. 상황 최적화
루프가 실행되면 다음 레버는컨텍스트 엔지니어링— 각 단계에서 어떤 사실을 검색하고 구조화하여 에이전트에 전달할지 결정합니다. 이는 다른 루프 반복을 추가하는 것보다 응답 품질을 더 향상시킬 수 있습니다. 세 가지 영역이 가장 중요합니다.
- : 검색된 모든 항목이 컨텍스트 창에 들어갈 자격이 있는 것은 아닙니다. 검색된 청크를 관련성 점수로 필터링하고 LLM에 전달하기 전에 순위를 다시 지정합니다. 관련성이 없거나 중복된 컨텍스트는 올바른 정보를 검색한 경우에도 답변 품질을 저하시킵니다. 대부분의 검색 라이브러리는 결과와 함께 관련성 점수를 반환합니다. 그들을 사용하십시오.
- : 다음 루프 반복에서 동일한 소스를 다시 쿼리하지 않도록 에이전트가 세션 내에서 이미 검색한 내용을 추적합니다. 검색된 사실, 도구 호출 결과, 단계 간 중간 결론을 저장합니다.
- : 루프 반복 사이에 에이전트의 중간 추론, 도구 호출 및 결론을 저장합니다. 에이전트가 루프에 다시 들어갈 때 처음부터 추론을 시작하는 대신 중단된 부분부터 다시 시작해야 합니다. 이렇게 하면 중복되는 단계가 방지되고 상담원의 답변 경로를 추적할 수 있습니다.
6. 확장 전 계측
개발 중에 각 답변과 함께 검색된 컨텍스트를 반환하므로 각 쿼리에 대해 검색된 내용을 정확하게 검사할 수 있습니다. 빈 컨텍스트 사례에 대한 대체를 정의하여 시스템이 자동으로 실패하지 않고 정상적으로 실패하도록 합니다. 추적 도구 호출, 루프 깊이, 재시도 횟수, 중지 이유 및 단계 수준 대기 시간. 최종 답변 점수는 시스템이 올바른지 여부를 알려줍니다. 그 흔적은 실패했을 때 실패하지 않은 이유를 알려줍니다.
에이전트 RAG 시스템을 평가하는 방법
Agentic RAG는 시스템이 답변에 도달하기 전에 여러 경로를 취할 수 있으므로 표준 RAG보다 더 광범위한 스코어카드가 필요합니다. 단일 엔드투엔드 점수는 답변이 올바른지 알려줍니다. 하지만 대답이 틀리면 어디서 문제가 발생했는지, 왜 문제가 발생했는지 알려주지 않습니다.
예상 검색 소스 및 각 질문에 대한 예상 응답과 함께 사용 사례를 나타내는 일련의 평가 질문을 개발하는 것부터 시작하세요. 질문 세트는 실제 사용법을 반영해야 합니다. 명확하고 시끄러운 질문, 단일 홉 및 다중 홉 작업, 오타, 모호한 프롬프트 및 과소 지정된 의도가 있는 입력을 포함합니다. 프로덕션 트래픽에는 이 모든 것이 포함되므로 벤치마크도 마찬가지입니다.
에이전트를 통해 이러한 질문을 실행하고 실제 검색된 소스 및 응답을 예상된 소스와 비교하십시오. 판사로서 LLM을 사용하여 관심 있는 일련의 주요 지표에 대해 점수를 매기세요.
에이전트를 변경하면 평가를 통해 에이전트가 얼마나 개선되었는지 또는 퇴보할 때 파악했는지 알 수 있습니다.
검색 측정항목
컨텍스트 정밀도(검색된 청크 중 실제로 관련성이 있는 비율) 및 컨텍스트 회상(필요한 증거 중 검색된 비율)을 추적합니다. 에이전트가 자주 루프백하는 높은 재검색 속도는 일반적으로 라우팅 논리, 청크 크기 또는 쿼리 공식을 나타냅니다. 응답 생성에서 병목 현상이 발생하는 경우는 거의 없습니다.
답변 품질 지표
충실도(답변이 검색된 맥락과 모순됩니까?), 답변 관련성(질문에 대한 답변입니까?) 및 환각 비율을 측정합니다. LLM-판사 설정은 여기서 잘 작동합니다. 유효한 여러 검색 경로가 동일한 정답으로 이어질 수 있으며 엄격한 문자열 일치는 정확도를 과소평가합니다. Ragas와 같은 도구는 몇 줄의 Python을 사용하여 테스트 스위트에 연결할 수 있는 미리 만들어진 측정항목을 제공합니다.
시스템 수준 측정항목
쿼리당 루프 깊이, 도구 호출 성공률, 중지 이유 및 단계 수준 대기 시간을 추적합니다. 이는 시스템이 실제로 답변을 개선하고 있는지 아니면 동일한 결과에 도달하기 위해 더 많은 토큰을 소비하는지 여부를 알려줍니다. 평균 루프 깊이가 충실도에 상응하는 이득 없이 계속 상승하는 경우 중지 기준을 강화하십시오.
평가 도구
여러 도구가 스택의 다양한 부분을 다룹니다.
- RAG 특정 실패 모드에 직접 매핑되는 검색 및 답변 지표(충실성, 컨텍스트 정확성, 컨텍스트 회상)를 포함하여 RAG 평가를 위한 포괄적인 프레임워크를 제공합니다.
- 요청 수준 추적을 제공하며 어떤 도구가 호출되었는지, 무엇을 반환했는지, 에이전트가 중지된 이유를 확인해야 할 때 유용합니다.
- TruLens검색된 컨텍스트, 도구 호출, 계획 및 광범위한 에이전트 실행을 측정합니다. 이는 전체 루프에 걸쳐 단일 대시보드를 원할 때 유용합니다.
에이전트 GraphRAG에 대한 지식 그래프
검색은 답변 품질의 상한선을 설정합니다. 벡터 전용 RAG는 유사해 보이는 청크를 반환할 수 있지만 답변을 유용하게 만드는 관계는 누락되어 있습니다. 바로 그곳이다그래프RAG들어온다.
GraphRAG는 지식 그래프의 구조화된 도메인 지식을 통합하고 격리된 구절 대신 연결된 컨텍스트를 반환함으로써 검색을 향상시킵니다.지식 그래프엔터티 간의 관계를 보존하므로 에이전트는 일반 텍스트 청크에서 연결을 재구성하는 대신 쿼리 시 이러한 연결을 탐색할 수 있습니다. 연결된 컨텍스트는 관련성을 향상하고 지원합니다.다중 홉 추론, 답변의 출처를 더 쉽게 추적할 수 있습니다.
Neo4j는 엔터프라이즈급 AI 지원 데이터를 저장하기 위한 지식 그래프를 제공합니다. 에이전트는 GraphRAG와 벡터 RAG의 하이브리드를 사용하여 지식 그래프를 쿼리하고 데이터에 대한 심층적이고 상황에 맞는 이해를 제공할 수 있습니다.
에이전트 GraphRAG 시작하기
Agentic RAG는 검색에 추론 루프를 추가합니다. 단순 검색에서 뭔가가 누락되면 에이전트는 루프백하여 추가 정보를 검색합니다. 그러나 실패가 숨어 있는 곳에서도 변화합니다. 일련의 추론과 행동으로 인해 실패를 식별하기가 더 어려워집니다.
GraphRAG가 해결책입니다. 지식 그래프는 도메인에서 엔터티가 어떻게 관련되어 있는지를 반영하는 에이전트 컨텍스트를 제공하여 에이전트 추론을 더욱 컨텍스트화하고 추적 가능하게 만듭니다.
필수 GraphRAG 가이드는 그래프 데이터 모델링부터 연결된 컨텍스트에 에이전트를 접지하는 것까지 검색 기반을 구축하는 과정을 안내합니다.
Agentic RAG FAQ
Agentic RAG는 AI 에이전트가 검색 프로세스를 제어하는 검색 증강 생성의 한 형태입니다. 고정된 검색 후 생성 파이프라인 대신 에이전트는 검색 시기, 쿼리할 도구, 결과가 충분한지 여부를 결정합니다. 충분한 기반 컨텍스트가 있거나 중지 지점에 도달할 때까지 반복됩니다.
표준 RAG는 일반적으로 컨텍스트를 한 번 검색하고 답변을 생성합니다. Agentic RAG는 계획을 세우고, 작업을 여러 단계로 나누고, 적절한 도구를 선택하고, 결과를 추론하고, 첫 번째 통과가 부족할 때 다시 쿼리하고, 응답하기 전에 증거를 검증할 수 있습니다. 차이점을 고정된 일회성 워크플로와 적응형 다단계 워크플로로 생각해 보세요.
표준 RAG와 마찬가지로 에이전트 RAG는 사용자 쿼리로 시작하지만 시스템은 직접 응답할 수 있는지 또는 추가 정보를 검색해야 하는지 여부를 결정합니다. 더 많은 컨텍스트가 필요한 경우 다음 단계를 계획하고, 검색기 또는 도구를 선택하고, 결과를 검사하고, 중지, 수정 또는 계속할지 여부를 결정할 수 있습니다. 루프는 시스템이 응답할 수 있는 충분한 근거 증거를 확보하거나 안전한 중지 지점에 도달하면 종료됩니다.
가장 어려운 질문이 다단계 추론, 소스 간 합성 또는 생성 전 검증에 의존하는 경우 Agentic RAG는 그만한 가치가 있습니다. 일반적으로 범위가 넓은 단일 소스를 사용하여 간단한 질문에 대답하는 데 가장 좋은 출발점이 아닙니다. 단순한 RAG 파이프라인이 더 빠르고 저렴하며 디버그하기 쉬운 경우가 많습니다. 추가 비용과 복잡성을 감수하고 정확도를 높일 가치가 있는 경우 에이전트 동작을 추가하세요.
주요 이점은 다중 홉 질문을 더 잘 처리하고, 도구와 소스 전반에 걸쳐 보다 유연하게 검색하고, 더 높은 품질의 답변을 얻을 수 있다는 것입니다.
단점은 더 높은 대기 시간, 더 높은 토큰 비용, 더 많은 움직이는 부품 및 더 큰 오류 표면입니다. 계획, 라우팅, 반영 및 조정은 정확성을 향상시킬 수 있지만 시스템을 평가하고 유지 관리하기 어렵게 만듭니다.
먼저 표준 RAG 기준선으로 시작하십시오. 그런 다음 취약한 라우팅, 다중 홉 컨텍스트 누락, 잘못된 답변 검증 등 수정해야 할 정확한 실패 모드를 식별합니다. 거기에서 에이전트 RAG 패턴을 추가하여 이러한 오류를 해결하세요. 라우팅 단계를 도입하거나, 가장 자주 실패하는 단계 주위에 수정 루프를 추가하거나, 벡터 RAG에서 GraphRAG로 이동할 수 있습니다. 확장하기 전에 검색 품질, 응답 품질, 루프 깊이, 도구 사용 및 대기 시간을 측정할 수 있도록 시스템을 조기에 계측하십시오.