검색증강생성
입문 Introduction to Retrieval-Augmented Generation (RAG)

오후 한나절에 만든 챗봇은
왜 무너지는가

한 AI 엔지니어가 사내 지원용 챗봇을 만든다고 하자. 기성품 거대언어모델(LLM)인 GPT-5.1을 가져다 오후 한나절 만에 프로토타입을 완성한다. 초기 결과는 인상적이다. 모델은 유창하게 대화하고, 긴 문서를 요약하고, 코드까지 작성한다.

문제는 회사의 시스템에 뿌리를 둔 질문을 던지는 순간 시작된다. “내년 1월 이후의 환불 정책은 어떻게 되는가?” “이번 주 후속 조치 대상으로 표시된 고객 계정은 무엇인가?” 답은 곧 허물어진다. 모델은 그럴듯하게 들리지만 회사의 실제 데이터와는 아무 연결이 없는 문장을 자신 있게 내놓는다. 어떤 때는 폐기된 정책을 만들어내고, 어떤 때는 완전한 헛소리를 한다. 핵심 문제는 모델의 유창함이 아니다. 모델의 실명(失明)이다.

이것이 가장 진보한 LLM조차 벗어날 수 없는 근본적 한계다.¹ LLM은 책, 논문, 코드 저장소, 공개 웹 콘텐츠 같은 거대한 말뭉치로 학습한다. 그 덕분에 언어에 대한 폭넓고 일반화된 이해를 얻고, 명시적으로 학습하지 않은 과제까지 수행한다. 그러나 학습 데이터가 아무리 커도 그 안에는 특정 기업의 사내 문서, 내부 지식베이스, 지난주에 갱신된 틈새 라이브러리 문서가 들어 있을 수 없다. 그래서 LLM은 학습 시점 밖의 정보를 요구하는 과제를 만나면 우아하지만 틀린 답을 내놓는다. 이런 오류는 대개 환각(hallucination)의 형태로 나타난다. 유창하고 확신에 차 있으나 어떤 실제 데이터로도 뒷받침되지 않는 생성물이다.

어떤 모델이든 학습이 끝나는 그 순간부터 이미 불완전하고 약간 낡아 있다. 검색증강생성이 등장한 이유가 여기 있다. 정적인 모델이 모든 것을 “알고 있기”를 기대하는 대신, RAG는 모델이 갖지 못한 사실을 필요할 때 동적으로 끌어오게 만든다.

앞의 챗봇에 RAG를 붙이면, 모델은 사용자가 질문을 던지는 바로 그 순간에 해당 위키 페이지, 정책 문서, 지원 티켓 이력을 가져온다. 그다음에 LLM은 자신의 생성 능력을 발휘해 그 자료에 근거한 최종 답변을 합성한다. 결과는 더 정확하고 더 신뢰할 수 있으며 환각에 훨씬 덜 취약한 시스템이다. 마침내 필요한 정보를 손에 쥐었기 때문이다.

이 책이 다루는 것은 바로 그 전환이다. 사전학습에만 의존하는 LLM에서, 검색을 통해 사적이고 도메인 특화된, 끊임없이 갱신되는 데이터를 추론 대상으로 삼는 시스템으로 옮겨가는 일. RAG는 단순한 기술적 개선이 아니다. 생성형 AI를 실제 애플리케이션에서 진짜로 유용하게 만드는 열쇠다.

RAG는 어떻게 작동하는가

RAG 질의는 두 단계로 이루어진다. R(검색, retrieval)과 G(생성, generation)이다. 사용자가 RAG 시스템에 질의를 던지면 먼저 R 단계가 작동해 질의와 가장 관련이 높은 정보를 검색한다. 이어 G 단계에서 거대언어모델이 검색된 정보와 질의를 함께 분석하고, 검색된 사실에 근거해 적절한 답변을 만들어낸다.

간단한 예를 보자. 의학 질문에 답하는 RAG 챗봇을 만든다고 하자. 이 챗봇은 의학 서적과 학술 논문으로 이루어진 사적 데이터 소스에 근거를 둔다. 여기에 “당뇨병의 효과적인 치료법은 무엇인가?”라는 질의가 들어오면 흐름은 이렇게 흘러간다.

1. R 단계. 시스템이 사적 데이터를 검색해 관련 문서를 가져온다. 이 경우에는 당뇨병 치료에 관한 구절들을 찾아낸다.
2. G 단계. LLM이 원래의 질의와 검색된 사실을 함께 받는다. 그리고 오직 그 검색된 정보만 사용해 답변을 합성한다.

“검색증강생성”에서 “증강”이라는 말은, 검색된 정보가 생성을 위한 LLM의 프롬프트에 더해진다는 뜻이다. 그런 의미에서 내부 지식을 추가적인 사실로 보강하는 것이다. RAG의 가장 기본적인 프롬프트 구조는 다음과 같다.

"""
You are an assistant for question-answering tasks. Use the following pieces of
retrieved context to answer the question. If you don't know the answer, just say
that you don't know.

<question>
{question}
</question>

<context>
{context}
</context>

Answer:
"""

여기서 변수 question은 실제 질문 문자열로 치환되고, context는 각각이 문자열인 사실들의 목록이다. 즉 LLM에게 질의응답 과제를 부여하는 셈이다. 검색된 사실(맥락)을 보고, 그 맥락에 제공된 정보와 사실을 사용해 질의에 답하라는 것이다.

폐쇄형 시험과 개방형 시험

여러 면에서 순수한 LLM 사용과 RAG의 차이는 폐쇄형 시험(closed-book test)과 개방형 시험(open-book test)의 차이와 닮아 있다.

RAG 스택의 청사진

이제 한 층 더 들어가, RAG에 어떤 구성요소가 필요하고 적재 흐름과 질의 흐름이 어떻게 동작하는지 살펴본다. RAG 스택에는 두 개의 주요 흐름이 있다. 적재 흐름(ingestion flow)과 질의 흐름(query flow)이다.

적재 흐름은 데이터를 원천(데이터베이스, S3에 놓인 PDF 묶음, Notion에 적힌 텍스트 등)에서 추출해 RAG 스택에 색인하는 데 필요한 기능을 수행한다. 질의 흐름은 사용자 질의의 전 과정을 처리한다. 올바른 사실을 검색하고 LLM으로 생성해, 최종 사용자에게 돌아갈 응답을 만든다.

적재 흐름

데이터 적재 과정에서 RAG 시스템은 먼저 입력 데이터(사용자 질의가 답변될 근거가 되는 데이터)를 질의 매칭에 효율적이고 효과적인 여러 형식으로 변환한다. 그중 대표적인 것이 텍스트의 의미를 표현하는 벡터 임베딩이다. 생성된 벡터 임베딩은 벡터 데이터베이스라는 특수한 데이터베이스에 저장된다. 각 벡터 옆에는 실제 텍스트도 함께 저장된다. 질의 시점의 처리에 그 텍스트가 필요하기 때문이다. 데이터를 벡터로 변환하는 단계는 흔히 색인(indexing) 또는 임베딩(embedding)이라 불린다.

프로덕션 적재 파이프라인은 상당히 복잡해질 수 있다. 문서 전처리, 청킹, 임베딩, 데이터 검증, 멀티모달 입력 처리, 증분 갱신 같은 난제들은 2장, 3장, 8장에서 다룬다.

질의 흐름

질의 흐름은 검색과 생성, 두 가지 연산을 수행한다. 검색은 사용자 질의를 임베딩 벡터로 변환하는 데서 시작한다. 그다음 벡터 DB가 질의 임베딩과 벡터 DB 안의 모든 후보 텍스트(사실) 사이에서 유사도 검색을 수행한다.

임베딩을 이용해 정보를 찾는 방식을 시맨틱 검색(semantic search)이라 부른다. 인간이 직접 이해할 수 없는 임베딩 벡터 공간에서 유사도 검색을 적용함으로써, 질의에 담긴 의도를 관련 텍스트 문서와 의미적으로 맞춘다. 다만 이 책 뒤에서, 특히 2장과 3장에서 보게 되듯, 시맨틱 검색은 검색의 기본 형태일 뿐이며 프로덕션 배포에서 고품질 RAG 응답을 얻기에는 흔히 부족하다. 또 하나의 기본 형태는 렉시컬 검색(lexical search)으로, 표기된 형태의 유사성을 기준으로 텍스트를 맞춘다. 실무에서는 시맨틱 검색과 렉시컬 검색을 결합한 하이브리드 검색이나 재순위(reranking) 같은 고급 기법을 함께 쓰는 것이 일반적이다. 이상적으로는 검색된 텍스트 조각들이 사용자 질의에 답하는 데 매우 관련성 높은 사실을 담고 있어야 한다.

관련 사실을 확보하면 생성 단계가 이어진다. RAG 질의 흐름은 앞에서 본 것과 같은 전용 프롬프트 템플릿을 구성해, 검색 결과의 정보로 사용자 질의에 답하는 응답을 만들도록 LLM에 지시한다. 중요한 점은, 좋은 RAG 파이프라인은 LLM에게 참조나 인용을 생성하도록 지시한다는 것이다. 그러면 응답에는 답변의 본문만이 아니라 그 답변이 근거로 삼은 지식의 출처까지 함께 담긴다.

인용이 붙은 응답을 만들어낼 지점에 이르렀지만 아직 끝이 아니다. LLM이 응답을 돌려보낸 뒤, 전형적인 RAG 질의 흐름은 가드레일을 적용해 응답이 기대하는 품질 기준을 만족하는지 확인한다. 무엇보다 먼저 환각 검출이 온다. LLM이 실제로 제공된 사실을 사용해 그 사실과 일관된 응답을 만들었는지 검증하는 일이다. 다시 말해 LLM이 이야기를 지어내지 않았는지 확인하는 것이다. 편향, 유해하거나 공격적인 응답, 그 밖에 허용되지 않는 콘텐츠에 대한 검출도 가드레일에 포함되며, 이는 3장에서 다룬다.

여기까지가 RAG의 적재 흐름과 질의 흐름의 큰 그림이다. 그러나 첫 개념검증(PoC)을 넘어 미션 크리티컬한 RAG 애플리케이션의 프로덕션 배포로 나아가면 사정이 복잡해진다. 다음과 같은 추가 과제를 반드시 짚어야 한다.

프로덕션 규모의 운영 규율

프로덕션 규모에서 RAG 파이프라인을 설계하고 구현하려면 낮은 지연, 높은 가용성, 강한 보안을 보장하기 위한 견고한 데브옵스 관행이 필요하다. LLM 시대에는 이를 MLOps 또는 LLMOps라 부른다. 항목은 다음과 같이 정리된다.

예제: LangChain으로 만드는 최소 RAG

LangChain으로 단순한 RAG 파이프라인을 만들어 본다. 근거 데이터는 루이스 캐럴의 『이상한 나라의 앨리스』다. 적재는 세 단계로 시작한다.

1. PDF 파일을 내려받아 텍스트로 파싱한다.
2. 책의 전체 텍스트를 청크로 분할한다.
3. 벡터 임베딩을 계산하고, 결과 벡터와 청크를 벡터 데이터베이스 LanceDB에 저장한다.

from langchain_community.document_loaders import PyPDFLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain_community.vectorstores import LanceDB
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser
from langchain_core.runnables import RunnablePassthrough

pdf_url = "https://www.adobe.com/be_en/active-use/pdf/Alice_in_Wonderland.pdf"
loader = PyPDFLoader(pdf_url)
pages = loader.load()

text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=1000,
    chunk_overlap=200,
    length_function=len,
)
chunks = text_splitter.split_documents(pages)

embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
vectorstore = LanceDB.from_documents(chunks, embeddings)

이제 LangChain으로 RAG 파이프라인을 만든다. 먼저 llm 객체를 정의하고(여기서는 GPT-4o mini), LanceDB 벡터 저장소에서 가장 관련성 높은 결과 3개를 가져오는 검색기(retriever)를 정의한다. RAG “체인”은 다음 단계로 구성된다.

1. 청크를 “맥락”으로 모으고 format_docs() 함수로 포맷한다.
2. 청크와 질문을 프롬프트에 통합한다.
3. llm을 호출한다.
4. 출력을 포맷한다.

llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)
retriever = vectorstore.as_retriever(search_kwargs={"k": 3})

def format_docs(docs):
    return "\n\n".join(doc.page_content for doc in docs)

prompt = ChatPromptTemplate.from_template(
    """Answer the question based only on the following context:
{context}

Question: {question}"""
)

rag_chain = (
    {"context": retriever | format_docs, "question": RunnablePassthrough()}
    | prompt
    | llm
    | StrOutputParser()
)

q = "Describe the Mad Hatter's tea party."
answer = rag_chain.invoke(q)
print(answer)

이것이 가장 기본적인 형태의 RAG다. 단순한 예제로 시작하는 것은 이렇게 쉽다. 이 책의 나머지는 이 예제를 계속 확장하면서, 단순한 개념검증에서 프로덕션으로 RAG를 옮겨가는 방법을 다룬다.

2장에서 RAG의 기술적 구성요소로 뛰어들기 전에, RAG가 왜 중요하고 다른 접근법과 어떻게 비교되는지를 확실히 정리해 둘 필요가 있다. 이 장의 나머지가 그 일을 한다. RAG의 이점, 활용 사례, 그리고 RAG를 선택하는 것이 타당한 경우다.

다른 접근법과의 비교

LLM과 RAG의 세계에 처음 들어서면 적어도 기능적으로는 RAG와 비슷해 보이는 접근법이 여러 개 눈에 띈다. 그러나 그런 접근법에는 상당한 단점이 있거나, 실세계의 프로덕션 규모 사용 사례를 지탱하기에는 지나치게 단순한 경우가 많다.

RAG 대 “PDF와 대화하기”

RAG는 문서 집합을 근거로 사용자 질의에 답하는 애플리케이션 범주, 즉 “chat with PDF”와 비슷해 보일 수 있다. RAG로 그런 애플리케이션을 구현하는 것도 물론 가능하다. 그러나 대부분의 “PDF와 대화하기” 애플리케이션은 단순하지만 확장되지 않는 방식을 쓴다. PDF 파일의 전체 텍스트를 LLM 프롬프트에 그대로 넣고 그 뒤에 질문을 붙이는 것이다.

이 방식은 작은 PDF에서는 통한다. 현대 LLM은 256K, 심지어 1M 토큰의 맥락 길이를 지원하니 수십에서 수백 개의 PDF를 그 창에 밀어 넣을 수도 있다. 그러나 수십만 건의 문서가 존재하는 엔터프라이즈 애플리케이션에는 명백히 확장되지 않는다. 아무리 큰 맥락 창도 부족하다. 그 밖에도 짚어야 할 한계가 셋 있다.

RAG 대 미세조정

자사의 독점 데이터로 LLM을 활용하는 개발자들은 흔히 모델을 특정 도메인에 맞추기 위해 미세조정(fine-tuning)을 고려한다. 범용 사전학습 LLM을 가져와 사적 데이터로 학습을 “이어가는” 과정이다. 보통 몇 에폭 동안 진행되는 이 추가 학습은 모델의 내부 파라미터를 조정해 지식, 용어, 응답 스타일을 새 데이터에 특화시킨다. 그렇다면 미세조정이 마주하는 난관은 무엇인가.

전문성 격차

무엇보다 미세조정은 어려운 과제다. 데이터의 세심한 준비와 딥러닝에 대한 깊은 전문성이 필요하다. 과적합, LLM의 일반 역량 퇴행, 새 데이터에 담긴 편향의 의도치 않은 유입, AI 안전 위험의 증가 같은 문제를 피해야 한다.

필요한 수준의 딥러닝 전문성을 갖춘 팀이 있다 해도, 보유한 데이터가 효과적인 미세조정에 충분히 크거나 충분히 깨끗하지 않을 수 있다.

미세조정의 비용

전문성 격차에 더해 미세조정은 GPU 비용 면에서 꽤 비싸다. 그래서 스스로에게 물어야 한다. 나는 얼마나 자주 미세조정해야 하는가? 데이터셋이 정적이라면 큰 문제가 아니다. 한 번 미세조정하면 끝난다. 그러나 대다수 실세계 엔터프라이즈 사용 사례에서 데이터는 자주 갱신된다. 매일 미세조정할 것인가, 주 1회로 할 것인가? 비용 효율적인 해법이 되기 어렵다.

접근 통제와 권한 — 보그 효과

자주 간과되지만 대단히 중요한 RAG의 장점이 접근 통제다. 엔지니어링, 인사, 재무, 법무 부서의 문서가 함께 들어 있는 데이터셋을 상상해 보자. 미세조정을 쓰면 이 데이터 전부를 모델 가중치 안에 통합하는 셈이 된다.

그런데 어떤 직원이 질문을 던졌을 때, 미세조정된 LLM이 CEO나 인사 부서만 접근할 수 있어야 하는 기밀 정보에 근거해 답한다면 어떻게 되는가? 미세조정에서 정보는 하나의 “덩어리”가 되고, CEO에게만 보여야 할 문서와 전 직원에게 공개된 문서를 분리할 수 없다.

이는 부서 간 민감 데이터의 의도치 않은 노출로 이어질 수 있고, 대다수 기업에게 보안 문제가 된다. 물론 사용자 그룹이나 부서별로 접근 가능한 데이터를 써서 서로 다른 LLM을 미세조정하는 방법을 생각할 수 있다. 그러나 그러면 여러 개의 미세조정 LLM이 생기고, 각각을 따로 호스팅해야 한다. 자원 소모가 크고, 각 경우에 의도한 모델이 호출되도록 질의 라우팅까지 필요하다. 전체적으로 확장되지 않으며 비용과 복잡성만 빠르게 늘어난다.

반면 RAG에서는 데이터 저장소에 권한 기반 메타데이터 필드를 추가하고 질의 시점에 필터링을 적용하는 방식으로, 검색 단계 안에서 접근 통제를 손쉽게 구현할 수 있다.

정리하면 “PDF와 대화하기”와 미세조정은 어떤 경우에는 유효한 접근법이지만, 엔터프라이즈 배포에 이르면 상당한 한계를 드러낸다.

RAG의 핵심 이점

1. 확장성과 효율성

RAG는 생성형 AI 애플리케이션을 사적 데이터셋에 근거지우는 효율적인 접근법이며, 수십만, 수백만, 그 이상의 문서로도 쉽게 확장된다. 이를 가능하게 하는 것은 RAG의 심장에 있는 검색 엔진이다. 검색은 수십 년간 연구된 어려운 문제이고, 그 덕분에 RAG에 쓸 수 있는 접근법이 풍부하게 쌓여 있다. 그리고 검색은 문서 수에 따라 확장되는 경로를 제공한다. LLM 단독으로는 불가능한 일이다. 이제는 유명해진 자기어텐션 메커니즘 때문에 LLM의 연산은 시퀀스 길이에 대해 이차적으로 증가한다.

2. 환각의 감소

환각은 LLM이 자신의 세계 지식으로도, 프롬프트에 주어진 정보로도 뒷받침되지 않는 콘텐츠를 생성하는 상황을 가리킨다. RAG는 설계상 폐쇄형 방식으로 LLM에 묻는 것보다 환각을 줄인다. 이유는 이렇다. 사용자 질의에 관련된 사실을 원천 데이터셋에서 검색해 LLM에 제공하므로, 제대로 만들어졌다면 LLM은 그 사실을 사용해 좋은 답을 낸다.

관련 사실을 찾지 못한 경우, 대부분의 RAG 애플리케이션은 그저 “모른다”고 답하도록 지시받는다. 반면 LLM은 학습 데이터에 근거해 거의 언제나 어떤 응답을 내놓으며, 정보가 없으면 많은 경우 지어낸다.

3. 설명가능성

RAG는 검색된 정보로 사용자 질의에 답하므로, 요청이 있을 경우 파이프라인이 생성하는 각 문장 끝에 “[3,5]” 같은 인용을 붙이는 것이 일반적인 관행이다. 이 인용은 주장을 검증할 수 있게 해 사용자 신뢰를 높이고, 동시에 환각(모델이 지어낸 경우)과 나쁜 데이터(검색된 문서 자체에 오류가 있는 경우)를 구별하게 해준다.

RAG 애플리케이션의 LLM은 적절한 프롬프트를 통해, 검색된 정보를 처리하고 그에 대해 추론하며 어떻게 답에 이르렀는지 설명하도록 유도할 수도 있다. 이런 수준의 높은 설명가능성은 LLM이 파라메트릭 지식만으로 답할 때는 도달할 수 없다. 신경망 가중치에서 출처를 복원하는 일은 거의 불가능하기 때문이다.

4. 지식의 즉시 추가와 제거

RAG에서 LLM이 만드는 응답의 품질은 LLM에 공급되는 검색 데이터의 품질과 관련성에 달려 있다. 이 데이터는 LLM 외부의 시스템에 저장되므로 전통적인 ETL 방법으로 손쉽게 갱신할 수 있다. 즉 LLM이 접근할 수 있는 지식을 정기적으로 쉽게 갱신할 수 있다. LLM은 주어진 지식을 기억하지 않는다. 질의 시점에 올바른 사실이 검색되기만 하면 된다.

프런티어 모델이나 미세조정 모델과 비교해 보라. 새 데이터를 통합하거나 기존 데이터를 제거·갱신하려면 재학습이 필요하고, 실무에서는 거의 불가능한 일이 된다. 물론 이 난제를 앞으로 완화해 줄 수 있는 기계 언러닝(machine unlearning) 연구가 학계에 존재한다는 점은 언급해 둔다.

5. 접근 통제와 보안

RAG에서는 적재 과정에서 문서에 권한 정보를 메타데이터 등으로 추가함으로써 접근 통제를 구현할 수 있다. 그러면 권한에 따라 특정 문서를 포함하거나 배제하도록 질의 흐름을 조정할 수 있다. 접근 통제를 제대로 지원하는 것은 엔터프라이즈 RAG 애플리케이션에서 종종 결정적인 요구사항이다. 사용자가 볼 권한이 없는 데이터가 RAG 응답으로 유출되는 것을 막아 준다.

RAG는 엔터프라이즈 애플리케이션에 매우 매력적인 역량을 제공한다. 특히 엄격한 접근 통제와 강력한 보안이 요구되는 조직, 그리고 무엇보다 응답 품질과 환각 감소를 중시하는 조직에게 그렇다.

RAG 활용 사례

LLM의 힘을 사적 데이터로 증강해 쓸 수 있다는 점 때문에, RAG는 기업 내부에서 LLM이 쓰이는 거의 모든 상황에 적용된다. 대다수 엔터프라이즈 애플리케이션은 자기 소유의 사적 데이터에 접근해야 하기 때문이다.

물론 ChatGPT, Claude, Gemini가 직원용 독립 도구로 쓸모없다는 말은 아니다. 그런 도구는 코딩, 마케팅, 일반 세계 지식이 필요한 과제에서 생산성을 높이는 데 효과적으로 쓰인다. 그러나 LLM이 내부 데이터에 접근해야 하는 애플리케이션이라면 RAG가 최선이다.

고급 RAG

RAG는 제34회 신경정보처리시스템학회(NeurIPS)에서 발표된 2020년 페이스북/메타 논문에서 처음 소개되었을 때, 텍스트 전용 데이터에 국한되고 인컨텍스트 학습 대신 미세조정을 사용하는 단순한 개념이었다. 그러나 이 토대가 된 구상은 결정적이었고, 이후 기술 발전의 길을 열었다.

그때 이후 RAG는 더 진전되고 강력한 형태로 발전했다. 이 책의 나머지는 에이전틱 RAG(7장), 멀티모달 RAG(8장), 지식 그래프(9장) 같은 고급 기법을 다룬다. 여기서는 그 개요만 짧게 짚는다.

에이전틱 RAG

에이전틱 RAG는 RAG의 진화형이다. 관련 정보를 검색하고 응답을 생성하는 일회성 과정 대신, 파이프라인 안에 자율 AI 에이전트를 편입시킨다. 에이전트는 다음과 같은 역량을 더한다.

에이전틱 RAG는 여러 검색·추론 단계를 동적으로 조율함으로써 복잡하고 다면적인 질의를 다루는 데 더 큰 유연성과 견고성을 제공한다.

멀티모달 RAG

초기에 RAG는 텍스트 정보에만 쓰였다. 이후 표, 다이어그램, 차트 같은 다른 모달리티로 확장되었다. 이런 모달리티를 편입하는 방식은 대개 둘이다.

첫째는 모든 정보 모달리티를 텍스트로 변환하고(예: 이미지를 캡션으로), 잘 이해된 RAG 파이프라인을 텍스트 도메인에서만 실행하는 방식이다. 둘째는 비전-언어모델(VLM)이나 멀티모달 거대언어모델(MLLM) 같은 멀티모달 임베딩·언어 모델을 활용하는 방식이다. 이 방식에서는 비텍스트 도메인의 정보가 원래 모달리티로 남아 있다가 질의 시점에 VLM에 제공되고, 텍스트 데이터와 함께 응답 생성에 사용된다. 최근에는 페이지 전체를 임베딩해 MLLM에 넘겨 응답을 생성하는, 보다 종단간(end-to-end)적인 접근도 부상하고 있다.

지식 그래프를 활용한 RAG

지금까지 논의한 RAG 예제들은 디지털화된 텍스트를 그대로 사용한다. 이런 관행적 접근은 복잡한 데이터셋에서 “점들을 연결하는” 일에 취약할 수 있다. 이 한계를 다루기 위한 진전된 전략이 지식 그래프(KG)의 활용이며, 그래프 데이터베이스 업체들이 대중화한 접근이다.

평평한 텍스트 임베딩에만 의존하는 대신, KG를 통합하는 방식은 먼저 비정형 문서를 처리해 핵심 엔티티와 그 관계를 추출한다. 그 연결들로 지식 그래프를 구축한다. 이 구조화된 표현은 시스템이 다중 홉 추론을 지원하게 한다. 여러 문서에 걸쳐 서로 다른 정보 조각을 연결해, 단일 출처에서는 드러나지 않는 결론에 이르는 일이다. 그리고 복잡한 질의에 답할 때 더 깊은 맥락 인식을 제공한다.

마이크로소프트가 대중화한 또 하나의 KG 활용 접근은 GraphRAG다. KG를 수작업으로 구축하는 복잡성을 해결하기 위해 제안된 방식으로, 먼저 비정형 문서를 처리해 엔티티와 관계를 추출하고, 데이터에 내재한 연결을 포착하는 지식 그래프를 구축한다. 9장에서 다룬다.