노트

RAG (검색 증강 생성)

Retrieval-Augmented Generation

백엔드#ai · 연결된 개념 7개

쉽게 말하면

RAG는 LLM에게 오픈북 시험을 보게 하는 거예요. 답하기 직전에 관련 자료 조각을 찾아 질문과 함께 보여 주니, 모델을 다시 학습시키지 않아도 사내 문서나 최신 내용에 근거해 답할 수 있죠.

비유가 깨지는 곳 오픈북이어도 엉뚱한 쪽을 펴면 틀려요. 답 품질은 대개 맞는 조각을 찾아왔느냐에서 갈려서, 청크 크기·하이브리드 검색·리랭커를 다듬고 검색 품질을 따로 평가해요.

RAG(Retrieval-Augmented Generation, 검색 증강 생성)는 LLM(Large Language Model)이 답을 만들기 전에 외부 자료를 검색해서 그 내용을 프롬프트에 붙여 주는 방식이다. LLM은 학습 시점 이후의 일이나 사내 문서처럼 학습에 없던 자료를 모르고, 모르면 그럴듯하게 지어낸다(환각, Hallucination). 문서가 바뀔 때마다 모델을 다시 학습시키는 대신, 필요한 조각을 찾아 "보여 주고" 답하게 한다. 교재를 펴 놓고 푸는 오픈북 시험과 비슷하다. 이름은 2020년 루이스(Lewis) 등의 논문에서 왔다.

흐름

[미리 한 번: 인덱싱]
문서 → 조각내기(chunking) → 임베딩 → 저장소에 넣기
 
[질문마다]
질문 → 임베딩 → 비슷한 조각 상위 k개 검색 (Retrieval)
     → "아래 자료를 근거로 답하라" + 조각 + 질문 (Augmented)
     → LLM이 답과 출처 생성 (Generation)
  • 임베딩(Embedding): 텍스트를 의미를 담은 숫자 벡터로 바꾼 것 → 텍스트 임베딩. 뜻이 비슷한 문장일수록 벡터 공간에서 가깝다. "환불 규정이 어떻게 되나요?"와 "반품하면 돈은 언제 돌려받나요?"는 겹치는 단어가 거의 없어도 가깝게 놓인다. 가까움은 보통 코사인 유사도로 잰다
  • 벡터 DB: "이 벡터와 가장 가까운 k개"를 빨리 찾는 데 맞춘 저장소. 벡터가 많아지면 전부 비교할 수 없어 HNSW 같은 근사 최근접 탐색(Approximate Nearest Neighbor, ANN) 인덱스로 정확한 1등을 조금 포기하고 속도를 얻는다. PostgreSQL 확장인 pgvector처럼 기존 DB에 붙이는 선택지도 있다. 조각이 수천 개 수준이면 배열을 순회하며 유사도를 계산해도 충분하다

grep과 무엇이 다른가

  • 같다고 보는 기준: grep은 글자가 정확히 같아야 찾고, 벡터 검색은 뜻이 비슷하면 찾는다. 그래서 자연어 질문에는 벡터 검색이 강하고, 고유명사·에러 코드·버전 번호처럼 정확히 맞아야 하는 말에는 키워드 검색이 강하다
  • 찾은 뒤: grep은 일치하는 줄 목록을 주고 끝난다. 읽고 종합하는 것은 사람 몫이다. RAG는 찾은 조각을 LLM에 넘겨 질문에 맞는 답을 문장으로 만든다
  • 그래서 grep 결과를 LLM에 넣어 답하게 하는 것도 구조상으로는 RAG다. 코딩 에이전트가 파일을 검색해 읽고 답하는 것이 그 형태다 → 에이전트 루프

품질은 검색에서 갈린다

답이 틀리는 원인은 대개 LLM보다 "맞는 조각을 찾아왔는가"다.

  • 청크 크기: 너무 작으면 문맥이 끊기고, 너무 크면 관계없는 내용이 섞이고 컨텍스트를 낭비한다. 제목 단위로 자르고 조각마다 출처·제목 같은 메타데이터를 붙이는 방식이 흔하다
  • 하이브리드 검색: 벡터 검색에 키워드 순위 함수인 BM25를 섞고, 두 결과를 순위 융합(Rank Fusion)으로 합친다. BM25는 역색인 위에서 단어 빈도로 점수를 매기는 전통 검색의 핵심이다
  • 리랭커(Reranker): 1차로 넉넉히 뽑은 후보를 더 정밀한 모델로 다시 매겨 상위 몇 개만 넘긴다
  • 평가: 질문과 정답 문서를 짝지은 작은 평가셋을 만들고, 정답이 상위 k개 안에 드는 비율을 개선 전후로 비교한다. LLM을 부르지 않고 검색 품질만 재면 싸고 빠르다

Anthropic은 조각마다 문서 전체 맥락을 짧게 덧붙인 뒤 임베딩하는 "Contextual Retrieval"을 소개하며, 이 기법에 BM25와 리랭킹을 더하자 상위 20개 검색 실패율이 67% 줄었다고 보고했다(그 실험에 한정된 수치다). 같은 글은 지식 베이스가 20만 토큰보다 작으면 RAG 없이 전부 프롬프트에 넣고 프롬프트 캐시를 쓰는 편이 낫다고도 말한다. 컨텍스트 윈도우가 커져도 비용·지연·관계없는 내용 때문에 추려 넣는 검색은 여전히 쓰인다.

파인튜닝과의 차이

파인튜닝(Fine-tuning)은 모델 가중치를 다시 학습시키는 것이라 말투나 형식을 익히는 데 맞고, 자주 바뀌는 지식을 넣기에는 느리고 비싸다. 지식은 RAG로 공급하고, 문서가 바뀌면 다시 인덱싱한다. 사이트가 에이전트에게 읽을 원문 목록을 알려 주는 llms.txt도 넓게 보면 검색을 돕는 장치다. 배경은 AI·머신러닝·딥러닝·LLM의 관계에서 다룬다. 서버 없이 브라우저 안에서 검색과 생성을 모두 돌린 사례는 브라우저 안에서 도는 RAG 구현기에 있다.

출처: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks Lewis et al.(2020) · Contextual Retrieval in AI Systems Anthropic(2024)

연결된 개념

이 노트를 가리키는 문서

뜻이 가까운 노트

  • LLM 사용 습관

    LLM이 어떻게 만들어지는지 알고, 컨텍스트를 깨끗하게 관리하고, 모델과 도구를 골라 쓰고, 답은 초안으로 보고 검증하는 습관.

  • SEO

    SEO(Search Engine Optimization)는 검색 엔진이 페이지를 잘 찾고(크롤링, crawling), 이해해서 저장하고(색인, indexing), 알맞은 검색어로 노출하도록(순위, ranking) 사이트를 다듬는 일이다. 개발자가 맡는 부분은 대부분 앞의 두 단계, 즉 "검색 엔진이 읽을 수 있게 만드는 것"이다.

  • 생성과 평가 분리

    결과물을 만드는 에이전트와 판정하는 에이전트를 나눈다. 자기 결과를 스스로 채점하면 관대해지기 때문이다. 판정은 가능한 한 결정론적 검증기에 먼저 맡긴다.

  • GraphQL

    GraphQL은 클라이언트가 필요한 데이터의 모양을 쿼리로 적어 보내면 서버가 정확히 그 모양으로 응답하는 API 쿼리 언어(query language)다. Facebook이 2012년 내부에서 만들어 2015년 공개했고, 지금은 GraphQL Foundation이 관리한다.

  • DRF 필터·검색·정렬

    DRF의 목록 API는 쿼리 파라미터로 결과를 좁히는 세 가지 장치를 붙일 수 있다. 값이 정확히 맞는 것만 고르는 필터, 일부 문자열로 찾는 검색, 순서를 바꾸는 정렬이다. 모두 제네릭 뷰(GenericAPIView 계열)의 filter_backends로 적용된다.

보기 옵션