RAG는 한때 유행어가 되었습니다.

사내 문서를 검색해서 답한다.

PDF를 읽게 해서 질문에 답한다.

벡터 데이터베이스 (Vector Database)에 연결해서 관련 문장을 가져온다.

이 설명은 틀리지 않았습니다.

다만, 지금의 RAG를 보기에는 조금 너무 좁습니다.

실제 현장에서는 문제가 「검색할 수 있는가」뿐만이 아닙니다.

필요한 자료를 찾을 수 없다.

찾았지만 관련 없는 파편도 섞여 있다.

문서의 일부만 보고 답해버린다.

여러 자료를 가로지르는 질문이 되면, 도중에 부족한 상태로 답한다.

나중에 보면 답의 근거가 어디에 있었는지 알 수 없다.

RAG의 어려움은 바로 이 지점에 있습니다.

지금 일어나고 있는 변화는 훨씬 더 명확합니다.

RAG는 모델 외부에 있는 사실을 끌어오기 위한 부품이 아니라, 어떤 정보를, 어떤 순서로, 어디까지 보고, 언제 멈출지를 결정하는 메커니즘이 되어가고 있습니다.

이 연재에서는 우선 그 전체상을 파악합니다.

이후 총 10회에 걸쳐 BM25 / RRF / 하이브리드 검색 (Hybrid Search), grep과 벡터 검색의 구분 사용, Agentic RAG, PageIndex, 평가와 실패 모드, 그래프 검색 (Graph Search), 멀티모달 (Multimodal), 기업 지식 베이스 (Knowledge Base), 그리고 Context Engine까지 다룹니다.

단, 용어를 나열하기만 하는 연재는 하지 않겠습니다. RAG를 검색·문서·운용·기억까지 포함하는 시스템으로서 바라볼 것입니다.

LLM은 분명히 똑똑해졌습니다.

컨텍스트 (Context)도 길어졌습니다.

파일을 읽게 하는 경험도 이전보다 훨씬 자연스러워졌습니다.

그럼에도 불구하고 「전부를 모델에게 기억시키면 된다」는 식으로는 되지 않습니다.

이유는 단순합니다.

모델 안에 들어있지 않은 정보는 역시 외부에 있습니다.

사내 문서, 의사록, 사양서, PDF, 표, 코드, 최신 뉴스, 개인의 작업 이력.

게다가 그 상당수는 매일 변합니다.

여기서 RAG의 역할이 나옵니다.

RAG는 모델에게 전부를 암기시키는 대신, 필요한 사실을 필요한 때에만 가져옵니다.

즉, 모델의 기억에만 의존하지 않고 외부에 있는 사실을 사용하는 방식입니다.

이 사고방식은 오래되어 보이지만, 사실 아직 상당히 강력합니다.

왜냐하면 현실의 지식은 계속 움직이기 때문입니다.

모델이 똑똑해질수록 RAG는 필요 없어질 것이다.

그렇게 보이는 시기도 있었습니다.

하지만 실제로는 반대의 측면도 있습니다.

모델이 똑똑해질수록 외부 정보를 단순히 붙여넣기만 하는 것은 아깝습니다.

어떤 정보를 보여줄지, 어떻게 순서를 짤지, 언제 추가로 조사할지까지 설계하는 편이 모델의 힘을 끌어낼 수 있습니다.

그래서 RAG는 사라지기보다 형태를 바꾸고 있습니다.

RAG를 「검색」이라고만 부르면 조금 부족합니다.

실제로는 대략 다음과 같은 흐름이 있습니다.

• 무엇을 묻고 있는지를 분해한다
• 어떤 정보원을 보러 갈지를 결정한다
• 후보를 줍는다
• 노이즈를 제거한다
• 부족하면 다시 한번 찾는다
• 답으로서 정리한다

여기서 중요한 것은 마지막 생성 (Generation)보다 전에 상당히 많은 판단이 들어있다는 점입니다.

정말로 효과적인 RAG는 검색 결과를 그대로 나열하는 것만이 아닙니다.

어떤 정보를 남기고, 어떤 정보를 버리고, 언제 추가로 보러 갈지를 결정합니다.

따라서 RAG는 검색 엔진이라기보다, 검색을 포함한 작업의 구성 방식에 가깝습니다.

RAG가 어려운 이유는 크게 두 가지로 나뉩니다.

첫 번째는 필요한 것을 찾지 못하는 것입니다.

관련 문서가 있는데도 집어내지 못한다.

표현이 다를 뿐인데 놓친다.

긴 문서 깊숙한 곳에 있는 중요 지점을 놓친다.

두 번째는 너무 많이 찾아지는 것입니다.

관계없는 파편까지 섞인다.

비슷하지만 다른 정보가 들어온다.

그 결과 모델이 불필요한 문맥에 휘둘린다.

지금 RAG의 주전장은 단순한 재현율 (Recall)만이 아닙니다.

얼마나 많이 줍느냐와 얼마나 노이즈를 억제하느냐 둘 다입니다.

긴 컨텍스트가 늘어나도 이 문제는 사라지지 않습니다.

대량의 문맥을 넣으면 안심할 수 있다는 이야기가 아니기 때문입니다.

넣은 문맥의 질이 나쁘면 모델은 오히려 방황합니다.

이 연재에서 처음에 짚고 넘어가고 싶은 것은 RAG에는 적어도 3개의 층이 있다는 것입니다.

• 무엇을 찾을지를 결정하는 층
• 어떻게 찾을지를 결정하는 층
• 어디서 멈출지를 결정하는 층

1은 질문의 분해입니다.

2는 BM25, 벡터, 하이브리드 검색, 재순위화 (Re-ranking) 이야기입니다.

3은 Agentic RAG나 PageIndex와 같은 「아직 부족하다면 계속한다」는 판단입니다.

이 3개의 층을 나누어 보지 않으면 RAG에 관한 논의는 금방 잡스러워집니다.

예를 들어 「벡터 검색 (Vector Search)이 약하다」라고 말하는 것만으로는 부족합니다.

무엇을 찾고 있었는가.

키워드 일치 (Keyword Match)가 필요했는가.

노이즈 (Noise)가 너무 많았는가.

애초에 질문이 다단계 (Multi-step)였는가.

그 정도까지 나누지 않으면 개선책은 나오지 않습니다.

이 시리즈에서는 RAG를 다음과 같은 흐름으로 살펴봅니다.

• RAG의 전체상
• BM25 / RRF / 하이브리드 검색 (Hybrid Search)
• grep과 벡터 검색의 구분 사용
• Agentic RAG
• PageIndex와 계층형 검색
• 평가와 실패 모드
• 그래프 검색과 멀티홉 (Multi-hop)
• 멀티모달 (Multimodal)과 문서 처리
• 기업 지식 베이스 (Knowledge Base)와 개선 루프
• Context Engine으로의 수렴

전반부에서는 RAG의 골격을 만듭니다.

후반부에서는 그 골격을 실제 문서, 이미지, 기업 지식 베이스, 운용 루프로 확장합니다.

즉, 이 연재의 목적은 RAG를 유행어로서 설명하는 것이 아닙니다.

어떤 상황에서 RAG가 필요하고, 어떤 상황에서 다른 방식에 패배하는가를 작업 공정으로서 가시화하는 것입니다.

RAG의 진화 방향은 「더 큰 벡터 데이터베이스 (Vector Database)」가 아닙니다.

진정으로 나아가고 있는 방향은 검색을 어떻게 제어할 것인가입니다.

질문을 어떻게 나눌 것인가.

어떤 정보원을 타겟팅할 것인가.

어디까지 수집하면 충분한가.

어떤 노이즈를 차단할 것인가.

언제 다시 한번 찾을 것인가.

이 판단이 능숙해질수록 RAG는 단순한 보조 기능이 아니게 됩니다.

시스템 안에서 사실을 다루기 위한 핵심 (Core)이 됩니다.

이 연재에서는 이 부분을 하나씩 분해해 나갈 것입니다.

다음 회차에서는 그 토대가 되는 BM25, RRF, 하이브리드 검색을 다룹니다.

키워드 검색과 벡터 검색은 어느 쪽이 더 새로운가로 비교할 대상이 아닙니다.

실패하는 방식이 다르기 때문에 함께 사용할 가치가 있습니다.

본 시리즈 (전 10회)의 후속 내용과 목록은 AI Watch 본 사이트에서 모아 볼 수 있습니다.

👉 https://aiwatch-jp.pages.dev/rag-overview-01

―― AI 미래 편집실 「AI Watch」