RAG 시스템이 틀린 답을 내놓을 때, 시스템은 대개 아무것도 모릅니다. 틀렸다는 사실도, 왜 틀렸는지도. 그냥 검색된 결과를 바탕으로 자신 있게 답변을 생성할 뿐입니다.
Towards Data Science에 기고한 Mostafa Ibrahim은 이 문제를 구조적으로 분석했습니다. 클래식 RAG는 실패할 때 조용히 실패합니다. 틀린 증거를 바탕으로 자신 있는 답변을 만들어내고, 시스템은 그것이 틀렸다는 사실을 알지 못합니다. 검색 엔지니어 Doug Turnbull도 같은 지점을 짚었습니다. 선형 파이프라인은 각 단계가 반드시 성공해야 하는데, 어느 단계에서도 “잠깐, 결과가 이상한데?”라고 멈출 방법이 없다고요.
출처: Agentic RAG vs Classic RAG: From a Pipeline to a Control Loop – Towards Data Science
단방향 파이프라인의 구조적 한계
클래식 RAG의 흐름은 단순합니다. 사용자 질문을 받아 벡터 검색으로 관련 청크를 찾고, 이를 컨텍스트로 LLM에 전달해 답변을 생성합니다. 단방향입니다. 뒤로 돌아갈 방법이 없습니다.
Doug Turnbull이 든 예시가 이를 잘 보여줍니다. 파리 여행을 앞두고 힙한 레스토랑을 찾는 질문을 RAG 시스템에 넣었더니, “Paris Texas”의 식당 목록이 반환됐습니다. 위치 파싱이 어긋났을 뿐인데, 이후 모든 단계가 그 전제 위에서 돌아갔습니다. 시스템은 이 결과가 이상하다는 사실을 알지 못합니다.
이런 실패는 몇 가지 상황에서 반복적으로 나타납니다. 답이 여러 문서에 흩어져 있는 멀티홉 질문, 사용자의 표현이 문서의 표현과 달라 검색에 걸리지 않는 경우, 512토큰 단위로 잘린 청크에서 맥락이 끊겨버린 경우가 대표적입니다. 어떤 경우든 클래식 RAG는 약한 증거를 바탕으로 최선을 다해 답변을 만들어낼 뿐, 다시 시도할 기회가 없습니다.
에이전틱 RAG: 파이프라인을 루프로
에이전틱 RAG는 이 단방향 흐름을 루프로 바꿉니다. 검색 결과를 받은 뒤 LLM이 스스로 평가합니다. 답변에 충분한 근거가 있는지, 빠진 정보가 있는지를 판단하고, 부족하다면 쿼리를 다듬어 다시 검색합니다. 멈추는 것은 충분한 근거가 갖춰졌을 때, 또는 정해진 반복 횟수에 도달했을 때입니다.
루프의 기본 구조는 이렇습니다.
- 검색: 질문을 바탕으로 후보 문서 또는 툴 결과를 가져옴
- 추론: 현재 증거를 검토하고 빠진 부분을 파악
- 결정: 답변 생성, 쿼리 재작성, 다른 소스 탐색 중 선택
Doug가 비유한 것처럼, 클래식 RAG가 로그를 한 번 쿼리하고 결론을 쓰는 방식이라면, 에이전틱 RAG는 디버그 루프에 가깝습니다. 결과를 보고, 뭔가 빠졌다면 쿼리를 고치고, 다시 확인합니다.
클래식 RAG와 비교하면 에이전틱 RAG가 특히 강한 상황이 있습니다. 질문이 불분명해 쿼리 재작성이 필요한 경우, 증거가 여러 문서에 걸쳐 있는 경우, 첫 검색 결과가 상충되거나 불완전해 교차 검증이 필요한 경우입니다.
루프가 생기면 새로운 문제도 생긴다
에이전틱 RAG가 더 강력하지만, 그렇다고 클래식 RAG의 자리를 모두 대체하는 건 아닙니다. 루프는 적응성을 높이는 대신 예측 가능성을 낮춥니다.
비용과 지연 시간이 고정이 아닌 분포가 됩니다. 대부분의 쿼리는 빠르게 처리되지만, 일부는 여러 차례 반복하며 토큰을 소모합니다. 실패 방식도 달라집니다. 클래식 RAG는 주로 검색 품질이나 프롬프트 문제로 실패하는 반면, 에이전틱 RAG는 루프가 수렴하지 못하거나, 툴 호출이 연쇄적으로 증폭되거나, 컨텍스트 윈도우가 저품질 정보로 가득 차는 방식으로 실패합니다.
그래서 현실적인 접근으로 제안되는 방식은 처음부터 에이전틱으로 전환하는 게 아니라, 클래식 RAG를 기본으로 두고 실패 신호가 감지됐을 때만 두 번째 루프를 트리거하는 것입니다. 인용 근거 부재, 낮은 검색 신뢰도, 상충하는 증거가 대표적인 트리거입니다.
더 복잡한 질문을 다루는 RAG로
클래식 RAG와 에이전틱 RAG의 차이는 결국 시스템이 자신의 검색 결과를 평가할 수 있는지의 여부입니다. 단순한 문서 조회라면 클래식 RAG로 충분합니다. 하지만 질문이 복잡해지고, 증거가 여러 곳에 흩어지고, 한 번의 검색으로 답이 나오지 않는 상황이 잦아진다면 루프 구조가 필요해집니다. 어떤 쿼리를 클래식으로, 어떤 쿼리를 에이전틱으로 라우팅할지에 대한 결정 매트릭스와 구체적인 구현 패턴은 원문에서 확인할 수 있습니다.
참고자료: Agents put the Resilient in RAG – softwaredoug.com
답글 남기기