K-컬쳐 용어사전 ㄱ기사에 자주 나오는 기술 용어

검색 증강 생성

RAG

AI가 답하기 전에 자료를 먼저 찾아보게 하는 방식. 환각을 줄이는 대표 처방.

쉽게 말하면

RAG(Retrieval-Augmented Generation, 검색 증강 생성)는 AI가 답하기 전에 관련 자료를 먼저 찾아 읽게 하는 방식입니다. 순서는 셋입니다 — 질문을 받으면, 문서·데이터베이스에서 관련 대목을 검색(Retrieval)해서, 그걸 근거로 답을 생성(Generation)합니다.

「오픈북 시험」에 비유하면 정확합니다. 기억에만 의존하면(클로즈드북) 그럴듯한 오답 — 환각 — 이 나오기 쉽지만, 교과서를 펴 놓고 답하게 하면 정확도가 오르고 출처도 댈 수 있습니다.

기업들이 「우리 회사 문서를 아는 AI」를 만들 때 쓰는 표준 방법이 바로 이것입니다. 모델을 새로 훈련하는 것(파인튜닝)보다 싸고, 자료를 바꾸면 답도 바로 바뀝니다. 「사내 규정을 답해 주는 챗봇」「의료 문헌 기반 AI」 같은 기사 뒤에는 거의 항상 RAG가 있습니다.

기사에서 이렇게 나와요

「환각을 줄이기 위해 RAG 구조를 도입했다」 — 근거 문서를 찾아 읽고 답하게 만들어 신뢰도를 높였다는 뜻입니다.

직접 해보기

문서(제품 설명서·약관·사내 규정 등)를 첨부하기 전에, 먼저 답을 스스로 정해 보세요 — 「환불 기한을 물으면 어떤 답이 나와야 이상적인가?」. 기대하는 출력을 먼저 정의하는 것이 실전 RAG 빌더들의 제1원칙입니다.
이제 첨부하고 이렇게 물어보세요: 「이 문서에 있는 내용만 근거로 답해 줘. 문서에 없으면 '문서에 없음'이라고만 답해 줘. 질문: 환불 기한이 며칠이야?」 — 1번에서 정한 이상적인 답과 비교해 보세요.
함정도 던져 보세요 — 문서에 없는 것을 일부러 묻기: 「해외 배송 환불 기한은?」. 「문서에 없음」이 나오면 합격, 그럴듯하게 지어내면 환각입니다.
한 걸음 더: 받은 답을 새 대화에 붙여 넣고 「이 답이 아래 문서 원문과 일치하는지 채점해 줘」라고 시켜 보세요 — AI의 답을 AI로 검증하는, 실전에서 「LLM을 평가 도구로 쓴다」고 부르는 방법의 미니판입니다. 질문과 이상적인 답의 목록을 만들어 두고 문서가 바뀔 때마다 다시 돌리면 그게 곧 기업들이 말하는 테스트셋이고요.

깊이 알아보기

AI가 기억만 더듬지 않고, 답하기 전에 근거부터 찾습니다.

RAG는 질문과 관련된 자료를 검색해 모델의 입력에 보탠 뒤 답을 생성하는 방식입니다. 문서를 잘게 나누는 법부터 검색 품질, 인용, 최신성, 접근 권한까지 전체 흐름을 함께 설계해야 믿을 만한 답이 나옵니다.

3분 요약

RAG는 Retrieval-Augmented Generation의 약자로, 검색 단계가 근거 후보를 찾고 생성 단계가 그 근거를 읽어 답을 구성합니다. 검색이 사실을 보장하거나 생성 오류를 자동으로 없애는 것은 아닙니다.
문서는 검색하기 좋은 크기의 청크로 나뉘고 임베딩이라는 숫자 표현으로 변환될 수 있습니다. 벡터 검색은 의미가 가까운 내용을, 키워드 검색은 정확한 이름이나 코드를 잘 찾으며 둘을 섞은 하이브리드 검색도 널리 쓰입니다.
RAG는 외부 지식을 매 요청 때 가져오는 방식이고 파인튜닝은 모델의 행동이나 표현 경향을 학습으로 바꾸는 방식입니다. 최신 문서에 근거해 답하고 출처를 보여주는 목적이라면 대개 RAG를 먼저 검토합니다.

왜 지금 알아야 하나

모델의 기억에는 시점과 범위가 있다

학습이 끝난 모델은 이후에 생긴 사내 규정이나 오늘 바뀐 제품 정보를 저절로 알지 못합니다. RAG는 현재 관리 중인 자료를 답변 시점에 찾아 넣어 모델을 다시 학습하지 않고도 최신 근거를 제공할 수 있습니다.

답뿐 아니라 근거가 필요해졌다

업무용 AI에서는 그럴듯한 문장보다 어떤 문서의 어느 대목을 근거로 했는지가 중요합니다. 검색 결과에 문서 식별자와 위치를 함께 보존하면 답에 인용을 붙이고 사용자가 원문을 확인하게 만들 수 있습니다.

검색 품질을 따로 측정할 수 있다

RAG는 답이 틀렸을 때 관련 자료를 못 찾았는지, 찾았지만 모델이 잘못 읽었는지 나눠 조사할 수 있습니다. 실제 질문과 정답 근거를 모은 평가 세트로 검색 재현율, 인용 정확성, 답변 충실도를 각각 점검할 수 있습니다.

어떻게 작동하나

1. 문서를 수집하고 청크로 나눈다
문서의 제목, 본문, 작성 시점, 접근 권한을 가져온 뒤 검색 결과로 읽기 적당한 단위로 나눕니다. 청크가 너무 크면 관련 없는 내용이 섞이고, 너무 작으면 표의 제목이나 조항의 예외처럼 답에 필요한 맥락이 끊길 수 있습니다.
2. 검색용 표현과 색인을 만든다
각 청크를 임베딩 모델로 숫자 벡터로 바꾸고 원문 및 메타데이터와 함께 벡터 저장소에 넣을 수 있습니다. 정확한 제품명, 조항 번호, 오류 코드가 중요한 자료에는 키워드 색인도 만들며, 문서가 바뀌면 관련 색인을 갱신하거나 삭제합니다.
3. 질문과 관련된 근거를 검색한다
질문의 임베딩과 가까운 청크를 찾는 벡터 검색, 단어가 일치하는 키워드 검색, 두 점수를 결합하는 하이브리드 검색을 목적에 맞게 사용합니다. 사용자에게 허용된 문서만 후보에 남기고, 필요하면 재순위화해 가장 관련 높은 근거를 고릅니다.
4. 근거를 보태 답하고 평가한다
선별한 청크와 출처 정보를 질문에 함께 붙여 생성 모델에 전달합니다. 모델은 검색된 자료와 자신의 문장을 구분해 답과 인용을 만들고, 시스템은 인용이 실제 원문을 뒷받침하는지와 질문에 필요한 근거가 검색됐는지를 평가합니다.

흐름 한눈에 보기

문서 수집 → 청크 분할 → 임베딩과 키워드 색인 → 질문 입력 → 벡터 검색 또는 하이브리드 검색 → 권한 필터와 재순위화 → 근거를 컨텍스트에 보강 → 답변 생성과 인용 → 검색 품질과 답변 충실도 평가 → 문서 변경 시 색인 갱신

문서가 색인으로 쌓이고, 질문이 그 색인을 검색해 근거를 찾은 뒤, 그 근거로 답변이 생성되는 흐름을 보여준다. 문서에서 색인으로 가는 화살표는 실선이고, 질문에서 색인으로 가는 화살표는 점선(간헐적 검색), 색인에서 답변으로 가는 화살표는 실선이다.

도입 전과 후

이전: 모델의 학습 지식에만 의존

사용자가 어제 개정된 휴가 규정을 물어도 모델은 변경 전 일반 지식으로 답하거나 모르는 내용을 추측할 수 있습니다. 답이 어디에서 왔는지 확인하기도 어렵습니다.

이후: 최신 원문을 찾아 답변에 보강

시스템은 사용자가 볼 수 있는 최신 규정에서 관련 조항과 예외를 검색해 모델에 제공합니다. 답에는 문서명과 조항 위치를 붙여 사용자가 원문을 열어 확인할 수 있습니다.

다른 선택: 파인튜닝은 행동을 조정

파인튜닝은 좋은 답변 예시를 학습시켜 형식, 말투, 분류 행동을 일관되게 만드는 데 적합합니다. 자주 바뀌는 사실을 모델 내부에 저장하고 출처까지 제시하려는 목적에는 관리가 어렵습니다. RAG와 파인튜닝은 필요에 따라 함께 쓸 수 있지만 서로 같은 기술은 아닙니다.

사용자의 질문이 문서고에서 관련 규정을 검색하고, 찾은 원문이 답변에 인용과 함께 반영되는 흐름을 보여준다. 질문에서 문서고로 가는 선은 점선으로 매번 필요할 때 검색이 일어남을, 문서고에서 답변으로 가는 선은 실선으로 찾은 내용이 반드시 답에 포함됨을 나타낸다.

예시로 이해하기

사내 인사 규정 도우미

직원이 육아휴직 중 복지 포인트 사용 여부를 묻습니다. 시스템은 질문을 임베딩하고 육아휴직, 복지 포인트라는 정확한 용어도 검색해 관련 규정 청크를 찾습니다. 직원의 소속과 권한으로 열람 가능한 문서만 남긴 뒤 답과 조항 링크를 보여주며, 근거가 충돌하면 단정하지 않고 담당 부서 확인이 필요하다고 알립니다.

제품 장애 지원 검색

상담원이 오류 코드 E417과 연결 끊김 증상을 입력합니다. 키워드 검색은 정확한 코드를 찾고 벡터 검색은 표현이 다른 유사 증상 문서를 찾습니다. 하이브리드 결과에서 최신 버전의 해결 절차를 우선한 뒤 모델이 점검 순서를 작성하고 각 단계에 출처를 붙입니다.

직접 해보기

1. 작은 문서 묶음과 질문을 준비한다
서로 다른 규칙이 담긴 공개 문서 서너 개와 문서로 답할 수 있는 질문 다섯 개를 고릅니다. 질문마다 정답과 반드시 찾아야 할 원문 구절을 미리 적습니다.
2. 청크 크기를 바꿔 비교한다
문단 단위와 더 짧은 단위로 각각 나눠 검색해 봅니다. 정답 구절뿐 아니라 제목, 표 머리말, 예외 조건이 함께 반환되는지 확인해 맥락이 끊기지 않는 크기를 찾습니다.
3. 벡터 검색과 하이브리드 검색을 시험한다
자연어 질문, 고유명사, 오류 코드가 포함된 질문을 각각 넣습니다. 의미 검색만 했을 때와 키워드를 결합했을 때 정답 청크가 상위 결과에 나타나는 비율을 기록합니다.
4. 답변과 인용을 따로 채점한다
문서에 있는 질문, 없는 질문, 오래된 문서를 노린 질문을 섞어 실행합니다. 답이 정확한지, 인용 원문이 실제로 답을 뒷받침하는지, 권한 없는 문서가 결과에 섞이지 않는지를 별도로 확인합니다.

한계와 주의점

못 찾은 근거는 생성 모델도 쓸 수 없다

청크가 잘못 나뉘거나 검색어와 색인이 맞지 않으면 필요한 문서가 존재해도 검색 결과에서 빠질 수 있습니다. 답변 평가만 하지 말고 정답 근거가 상위 검색 결과에 들어오는지도 측정해야 합니다.

검색 결과와 인용도 검증 대상이다

관련 청크가 주어져도 모델이 내용을 잘못 해석하거나 인용과 맞지 않는 주장을 덧붙일 수 있습니다. 인용 표시는 진실의 보증서가 아니며, 중요한 결정에서는 원문 확인과 사람의 검토가 필요합니다.

자주 묻는 질문

RAG와 파인튜닝 중 무엇을 선택해야 하나요?

최신 문서의 사실을 찾아 근거와 함께 답하려면 RAG가 먼저 맞는 경우가 많습니다. 일정한 말투, 출력 형식, 특정 판단 패턴을 학습시키려면 파인튜닝을 검토합니다. 검색한 사실을 정해진 형식으로 답해야 한다면 두 방식을 함께 사용할 수도 있습니다.

벡터 데이터베이스가 반드시 필요한가요?

아닙니다. 문서 규모와 질문 특성에 따라 키워드 검색이나 기존 데이터베이스 조회만으로 충분할 수 있습니다. 의미가 비슷하지만 표현이 다른 문장을 찾을 때 벡터 검색이 유용하고, 정확한 용어도 중요하면 하이브리드 검색이 도움이 됩니다.

RAG를 쓰면 환각이 없어지나요?

없어지지 않습니다. RAG는 관련 근거를 제공해 오류 가능성을 낮추고 검증 경로를 만들지만, 검색 실패와 생성 오류는 여전히 생깁니다. 근거가 없으면 답하지 않는 규칙, 인용 검증, 실제 질문으로 만든 평가 세트가 함께 필요합니다.

출처

Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — Meta AI Research, University College London, and New York University
Retrieval guide — OpenAI
pgvector official documentation — pgvector
PostgreSQL full text search documentation — PostgreSQL Global Development Group