RAG의 신비를 벗기다

앞 장에서 우리는 LLM의 진화가 생성형 AI의 지형을 어떻게 바꾸었는지 살폈고, 그 함정도 함께 논했다. 이 장에서는 그 함정을 검색 증강 생성(Retrieval-Augmented Generation, RAG)으로 피하는 방법을 탐구한다. RAG가 무엇을 뜻하는지, 그 아키텍처는 어떤 모습인지, 그리고 더 나은 지능형 애플리케이션을 만드는 LLM 워크플로 안에 RAG가 어떻게 자리 잡는지를 본다.

이 장을 따라가려면 Python(3.6 이상 권장)과 딥러닝의 기초 개념에 익숙해야 한다. RAG를 만들고 실험하는 데 Hugging Face의 Transformers 라이브러리 같은 대중적인 AI 툴킷을 활용한다. 필수는 아니지만 Git 버전 관리의 기본을 알아두면 도움이 된다. 코드를 직접 찾거나 타이핑할 필요는 없다. 이 장의 실습 전체가 담긴 공개 저장소(github.com/PacktPublishing/…/ch2)가 마련되어 있고, RAG 모델 구현과 Neo4j 통합에 필요한 스크립트·파일·설정이 모두 들어 있다. 환경에 설치해야 할 Python 라이브러리는 다음과 같다.

RAG는 2020년 Meta의 연구자들이 소개한 프레임워크다(arxiv.org/abs/2005.11401). 모델 훈련에 포함되지 않은 외부 데이터를 생성형 AI 모델이 활용해 출력을 강화하도록 하는 틀이다.

LLM이 환각(hallucination)에 시달린다는 것은 널리 알려진 사실이다. 실세계의 고전적 사례가 하나 있다.

LLM의 환각은 여러 요인에서 비롯된다.

환각은 중대한 도전이지만, 어느 정도 완화할 방법들이 있다.

프롬프트 엔지니어링(prompt engineering)은 LLM에 주는 지시나 질의를 신중히 다듬고 반복적으로 정제해 일관되고 정확한 응답을 끌어내는 작업이다. "Neo4j에 대해 말해 달라"는 광범위한 질의보다 "지식그래프를 위한 Neo4j의 핵심 이점 다섯 가지를 나열하라"는 질의가 더 많은 구조와 정밀성을 제공한다. 전자는 장황하거나 곁길로 새는 응답을 낳기 쉽지만, 후자는 기대 출력을 명시하므로 모델이 간결하고 적절한 이점 목록에 집중하게 된다. 프롬프트 엔지니어링은 모델이 원하는 정보 범위 안에 머물도록 이끌어, 무관하거나 조작된 출력을 만들 가능성을 줄인다. 기법과 모범 사례의 상세한 탐구는 Google Cloud의 가이드를 참고하면 된다.

인컨텍스트 러닝(in-context learning), 곧 퓨샷 프롬프팅(few-shot prompting)은 프롬프트 안에 예시를 포함시켜 LLM을 정확하고 과업 특화된 응답으로 이끄는 방법이다. 제품 비교를 요청할 때 잘 구조화된 비교의 예시 몇 개를 프롬프트에 넣어 주면, 모델이 그 패턴을 모방한다. 주어진 예시로부터 문맥을 추론하고 응답을 조정하는 모델의 능력을 지렛대 삼는 접근이며, 도메인 특화 과업에 효과적이다.

미세조정(fine-tuning)은 이미 사전훈련된 LLM을 특정 데이터셋으로 추가 훈련해 전문 도메인이나 과업에 적응시키는 방법이다. 도메인 특화되고 적절하며 정확한 응답을 생성하는 능력이 이 과정에서 강화된다. 대표적 기법이 인간 피드백 기반 강화학습(Reinforcement Learning with Human Feedback, RLHF)이다. 인간 평가자가 모델의 출력에 점수를 매기고, 그 점수로 모델의 행동을 조정해 인간의 기대에 정렬시킨다. 회사 내부 문서로 미세조정한 LLM에 "신입 온보딩 절차를 설명하라"고 물으면, 그 회사의 정책에 부합하는 상세한 설명이 나온다. 범용 모델이라면 모호하거나 무관한 답을 내놓았을 것이다. RLHF가 응답을 어떻게 개선하는지, 시나리오 하나로 보자.

RLHF가 환각을 줄이는 데 특히 값진 이유는, 인간이 선별한 피드백으로부터의 학습을 강조하기 때문이다.

이 방법들은 상당한 개선을 가져다준다. 그러나 결정적인 한 지점에서 여전히 부족하다. 조직이 도메인 특화 지식을 활용해 정확하고 맥락적이며 설명 가능한 생성형 AI 애플리케이션을 신속하게 구축하도록 해 주지는 못한다는 것이다. 해법은 접지(grounding)에 있다. 모델의 응답을 실세계의 사실이나 데이터에 묶어 두는 개념이다. 이 접근이 텍스트 생성의 새로운 패러다임, 곧 RAG의 토대를 이룬다. 신뢰할 수 있는 지식 소스에서 사실 정보를 동적으로 검색함으로써, RAG는 출력이 정확하면서도 맥락에 정렬되도록 보장한다.

검색 증강 생성이라는 용어는 Facebook AI Research(FAIR)의 연구자들이 2020년 5월 제출한 논문 Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks에서 처음 도입했다. 논문은 RAG를 신경 리트리버와 시퀀스-투-시퀀스 생성기를 결합한 하이브리드 아키텍처로 제안했다(그림 2.1). 리트리버가 외부 지식 베이스에서 관련 문서를 가져오면, 생성기가 그 문서를 문맥으로 삼아 사실 데이터에 접지된 출력을 만든다. 이 접근은 오픈 도메인 질의응답과 대화 시스템 같은 지식 집약적 NLP 과업에서 성능을 크게 끌어올렸다. 모델 내부 지식에 대한 의존을 줄이고 사실 정확성을 높인 결과다.

RAG는 앞서 말한 LLM의 결함들을, 결정적인 요소 하나를 도입함으로써 해소한다. 보충적이거나 도메인 특화된 데이터 소스에서 관련 지식을 검색하는 능력이다. 덧붙여 RAG 파이프라인은 정확성을 유지하면서 모델 크기를 줄일 잠재력도 지닌다. 모든 지식을 모델 파라미터 안에 새겨 넣으려면 막대한 자원이 들지만, RAG는 모델이 정보를 동적으로 검색하게 함으로써 모델을 가볍고 확장 가능하게 유지한다.

이제 RAG 모델의 구성 요소를 해부해 그것이 어떻게 작동하는지 이해할 차례다. 먼저 RAG가 없는 통상의 LLM 애플리케이션 흐름부터 본다.

사용자가 LLM에 프롬프트를 보내면 벌어지는 일은 이렇다.

이 흐름에서 답을 내놓는 책임은 오롯이 LLM에 있고, 그 사이에 다른 과정은 없다. RAG 없는 요청-응답 흐름의 가장 흔한 형태다. 이제 이 워크플로의 어디에 RAG가 끼어드는지 보자.

그림 2.3에서 보듯, 실제 LLM 서비스 호출 앞에 LLM 요청의 문맥을 제공하는 중간 데이터 소스가 자리한다. 흐름을 단계별로 따라가면 이렇다.

1. 사용자가 프롬프트를 보낸다. 사용자가 채팅 인터페이스를 통해 프롬프트나 질문을 보내며 과정이 시작된다.

2. RAG 모델이 프롬프트를 처리한다. 채팅 API가 프롬프트를 받아 RAG 모델에 전달한다. RAG 모델은 함께 작동하는 두 주요 구성 요소를 가진다. 리트리버(retriever)와 인코더-디코더(encoder-decoder)다.

3. 리트리버. 이 구성 요소는 지식 저장소를 검색한다. 저장소에는 비구조화 문서와 지문뿐 아니라 표나 지식그래프 같은 구조화 데이터도 포함될 수 있다. 역할은 사용자의 프롬프트를 다루는 데 필요한 가장 관련성 높은 정보를 찾아내는 것이다. 간단한 리트리버 예제를 보자. 전체 코드는 ch2/dpr.py에 있다.

4. 인코더-디코더 / 증강 생성. 인코더는 프롬프트를 검색된 정보(구조화든 비구조화든)와 함께 처리해 포괄적인 표현을 만든다. 디코더는 그 표현을 이용해 정확하고 맥락이 풍부하며 사용자의 프롬프트에 맞춘 응답을 생성한다. 입력 질의와 문맥 정보로 LLM API를 호출하는 과정이 여기 포함된다. Hugging Face의 T5 모델로 그 작동을 보자.

5. 채팅 API가 응답을 전달한다. 다음 코드가 generate_response를 호출해 입력 질의에 대한 채팅 응답을 전달한다.

전체 코드는 ch2/augmented_generation.py에 있다.

6. 통합과 미세조정. 마지막으로 리트리버와 LLM 호출을 하나의 완전한 RAG 흐름으로 결합한 코드를 보자.

흐름은 단순하다. 리트리버로 필요한 문서를 검색하고, 입력 질의와 검색된 문서를 LLM API 호출에 함께 넘긴다. 이번 RAG 아키텍처 심층 탐구에서 우리는 그 역학에 집중해 핵심 구성 요소의 작동을 확인했다. 효율적 정보 검색과 고급 언어 생성 모델을 결합함으로써, RAG는 맥락에 적절하고 지식이 풍부해진 응답을 만들어낸다. 다음 절에서는 검색 과정 자체를 논한다.

RAG가 외부 지식을 어떻게 활용하는지 이해하는 것은, 사실적으로 정확하고 유익한 응답을 생성하는 그 능력을 제대로 음미하기 위한 열쇠다. 이 절은 다양한 검색 기법과 검색 정보의 통합 전략을, 실제 예제와 함께 논한다.

RAG 모델의 성패는 방대한 외부 지식 베이스에서 관련 정보를 검색하는 능력에 달려 있다. 이 검색 방법들은 대규모 데이터셋에서 관련 정보를 조달하는 데 필수적이다. 전통적 방법인 BM25부터 DPR 같은 현대적 신경 접근까지 흔히 쓰이는 기법이 여럿인데, 크게 세 범주로 나눌 수 있다. 벡터 유사도 검색, 키워드 매칭, 지문 검색이다. 하나씩 살펴본다.

LLM에 전달하는 텍스트나 질의는 임베딩(embedding)이라는 벡터 표현으로 변환된다. 벡터 유사도 검색은 이 벡터 임베딩들을 비교해 가장 가까운 매치를 찾는다. 관련되고 유사한 텍스트는 유사한 임베딩을 가진다는 발상이 바탕에 깔려 있다. 기법의 작동은 이렇다.

이 코드는 DPR로 질의와 문서 집합을 고차원 벡터 표현으로 인코딩하는 법을 보여준다. 질의 벡터와 문서 벡터의 내적 같은 유사도 점수를 계산해 각 문서의 관련성을 평가하고, 점수순으로 문서를 정렬해 가장 관련 있는 것을 맨 위에 놓는다. 관련 콘텐츠와 무관한 콘텐츠가 뒤섞인 다양한 문서 집합에서도 맥락상 적절한 정보를 효과적으로 가려내는 것, 그것이 벡터 기반 검색의 힘이다. 전체 예제는 ch2/vector_similarity_search.py에 있다.

키워드 매칭은 더 단순한 접근이다. 사용자 프롬프트에 들어 있는 키워드를 포함한 문서를 찾는다. 효율적이지만 노이즈에 취약하고, 관련 있는 동의어를 담은 문서를 놓친다. BM25는 키워드 기반의 확률적 검색 함수로, 각 문서에 질의어가 등장하는 정도를 어휘 빈도와 문서 길이를 고려해 점수화한다. 흐름은 이렇다.

BM25는 어휘 빈도(키워드가 문서에 얼마나 자주 나오는가)와 문서 길이에 확률적 점수 함수를 적용해 질의와의 관련성으로 문서 순위를 매긴다. 질의와 문서를 고차원 공간의 밀집 수치 벡터로 표현하고 내적 같은 수학 함수로 유사도를 재는 벡터 유사도 검색과 달리, BM25는 이산적인 단어 매칭 위에서 직접 작동한다. 두 접근의 성격은 뚜렷이 갈린다.

전체 예제는 ch2/keyword_matching.py에 있다.

문서 전체를 검색하는 대신, RAG는 사용자의 질의를 직접 다루는 문서 안의 특정 지문(passage)에 집중할 수 있다. 더 정밀한 정보 추출이 가능해진다. 초기 흐름은 벡터 검색 접근과 매우 비슷하다. 벡터 검색으로 순위 매겨진 문서를 얻은 뒤, 다음 코드처럼 관련 지문을 추출한다.

이 예제가 보여주는 지문 검색 접근은 문서 수준 검색보다 세밀하다. 사용자 질의를 직접 다루는 특정 지문을 추출하는 데 집중한다. 리트리버에 리더(reader) 모델을 결합함으로써, 가장 관련 있는 문서뿐 아니라 그 안에서 질의에 가장 잘 답하는 정확한 지문까지 식별해 적합성과 특정성을 끌어올린다.

흥미로운 점이 있다. 리트리버 점수가 다소 낮은 지문이라도 리더가 우선시할 수 있다는 것이다. 리더는 문맥적 뉘앙스를 고려해 단어와 스팬(span) 수준에서 관련성을 더 정밀하게 평가하기 때문이다. 리트리버는 통상 질의와 지문 임베딩의 내적으로 유사도 점수를 계산한다.

리더는 여기서 한 걸음 더 나아가 각 지문의 텍스트 내용을 분석한다. 주어진 지문이 답을 담고 있을 가능성에 기반해 관련성 점수, 곧 로짓(logit, 신뢰도 점수)을 부여한다. 이 점수는 질의와 지문 사이의 단어·스팬 수준 상호작용을 고려하는 리더 모델의 원시 출력(로짓)에서 계산되며, 수식으로는 다음과 같다.

두 단계를 결합함으로써, 시스템은 의미적으로 유사한(리트리버 단계) 동시에 질의의 의도와 문맥적으로 정렬된(리더 단계) 지문을 식별한다. 이 이중 단계 과정이야말로 정보 검색 파이프라인에서 고도로 표적화된 응답을 생성하는 지문 검색의 강점이다. 전체 예제는 ch2/passage_retrieval.py에 있다.

RAG 흐름의 마지막 단계로, 리트리버의 정보를 생성 모델과 결합해 맥락에 맞고 일관된 응답을 합성하는 방법을 보자. 앞의 예제들과 달리 이 접근은 여러 개의 검색 지문을 질의와 함께 명시적으로 통합한다. 생성 모델을 위한 단일 입력을 만들어냄으로써, 지문을 고르거나 순위 매기는 데 그치지 않고 통합되고 풍부해진 응답을 합성하도록 하는 것이다.

이 코드는 검색 문서들을 T5 모델과 통합해 합성 응답을 생성한다. generate() 함수가 결합 입력(질의 + 지문들)을 인코더에 통과시켜 문맥 임베딩 h를 만들고, 디코더가 그 임베딩을 이용해 각 토큰을 확률에 따라 순차적으로 생성한다.

개별 지문을 고르거나 순위 매기던 앞의 예제들과 달리, 이 코드는 여러 검색 문서를 질의와 함께 단일 입력으로 명시적으로 결합한다. T5 모델이 결합된 문맥을 전체적으로(holistically) 처리해 여러 소스의 정보를 아우르는 일관된 응답을 만들 수 있게 되고, 여러 지문에 걸친 합성이나 요약을 요구하는 질의에 특히 효과적이다. 전체 코드는 ch2/integrate_and_generate.py를 참고하면 된다.

다양한 검색 기법과 그것의 생성 모델 통합을 탐구하면서, RAG 아키텍처가 외부 지식을 지렛대 삼아 정확하고 유익한 응답을 만드는 방식을 확인했다. 다음 절에서는 지금까지의 하드코딩된 문장 대신, 소스에서 입력 문서를 읽어 리트리버 흐름에 활용하는 전체적인(holistic) 흐름을 본다.

앞 절들에서 우리는 RAG 흐름의 각 단계를 단순한 데이터로 하나씩 파고들었다. 이제 한 걸음 물러나, 단순할지언정 실세계 데이터셋으로 전체 흐름을 완성해 볼 때다. GitHub 이슈 데이터셋(huggingface.co/datasets/lewtun/github-issues)을 사용한다. 이 데이터를 읽어 RAG 흐름에 활용하는 방법을 보는데, 이것이 이후 장들에서 완전한 엔드투엔드 RAG 흐름을 구현하는 토대가 된다. 이 예제에서는 GitHub 코멘트를 로딩해 "데이터를 오프라인으로 로딩하려면 어떻게 하는가" 같은 질문에 답할 수 있게 만든다. 데이터 로딩과 리트리버 설정은 다음 단계를 따른다.

위 코드가 보여주는 것은 완결된 흐름이다. 리트리버의 기반이 될 데이터 저장소에 데이터를 로딩하는 일부터, LLM이 답을 생성할 때 더 많은 문맥을 제공하는 데 쓸 문서를 검색하는 일까지. 이 실습 예제는 강력한 검색 기법으로 언어 생성을 강화하는 엔드투엔드 RAG 아키텍처의 실제 응용을 보여주었다. 위 코드는 Hugging Face NLP 과정에서 각색한 것이며, 실행 방법의 상세한 설명이 딸린 전체 Python 파일은 ch2/full_rag_pipeline.py에 있다.