RAG는 질문이 오면 관련 문서 조각을 먼저 찾고, 그 조각을 참고자료로 LLM에게 같이 넘겨서 문서를 근거로 답하게 하는 구조이다.
RAG는 오픈북 시험이라 할 수 있다. LLM에 답변을 요청하기 전에 사용자 질문과 관련된 자료를 검색하고, 그 자료를 질문과 함께 전달한다. LLM은 전달받은 내용을 참고해 답변을 생성하게 되고 이 경우 모델이 사전 학습 과정에서 알지 못했던 내용도, 관련 자료가 검색되어 함께 제공되면 답변에 활용이 가능해진다. (이때 중요한 것은 모델에 전달되는 정보가 잘못된 정보가 전달될 경우 모델도 그 정보를 기반으로 답을 생성하여 잘못된 답변을 생성하는 문제가 발생할 수 있다. 때문에 적절한 관련 자료를 제공하는 것이 중요하다.)
파이프라인 흐름
RAG 파이프라인은 크게 두 가지 흐름으로 구분되는데, 문서를 검색할 수 있게 준비하는 적재 과정과, 질문이 들어올 때 자료를 찾아 답을 만드는 질의 과정이다. 적재는 문서가 추가되거나 바뀔 때 실행되고, 질의는 질문이 들어올 때마다 돈다.
적재 · 문서가 추가되거나 바뀔 때
질의 · 질문이 들어올 때마다
전 구간을 재는 방법은 7편(평가)에서 다룬다.
회사에서 기존에 OpenAI 벡터 스토어를 통해 구현된 RAG의 답변 품질이 좋지 않아서 새롭게 라그 파이프라인을 구현하는 작업을 수행하였는데, 처음에 rag가 뭔지도 모르는 상태로 작업을 수행하다보니까 답변이 잘 나오지 않았을 때 계속 질의하는 부분에만 집중해서 작업을 수행했다. 근데 나중에 좀 더 살펴보니 질의 단계가 아니라 이전 적재 과정에서 문서 파싱이 제대로 이루어지지 않아 질의 시 검색용 데이터를 제대로 가져오지 못하고 LLM은 결국 적절한 관련 자료를 전달받지 못한 것이 근본적인 원인이였다.
이 과정에서 RAG 파이프라인에서 문서를 파싱하고, 청킹, 임베딩, 색인 작업을 수행하는 적재 단계와, 적재 단계에서 만들어진 데이터를 검색, 병합, 순위 조정 등의 작업을 수행하여 적절한 관련 데이터를 함께 LLM에 전달, 답변을 생성하는 질의 단계로 나뉜다는 점을 온전하게 이해할 수 있었다. (즉 LLM 답변 품질이 좋지 않을 때 무작정 질의 단계만 볼 것이 아니라, 적재가 잘 이루어지고 있는 지 실제 문제가 발생하는 지점이 어디인지 정확하게 파악해야 한다.)
| 단계 | 역할 | 주의점 | |
|---|---|---|---|
| 파싱 | PDF·HTML 등에서 텍스트와 표 구조 뽑기 | 각 파일 별 형식과 포맷에 따라 파싱을 다르게 적용하는 것에 대한 고려도 필요. | |
| 청킹 | 긴 문서를 검색 단위로 자르기 | 답의 앞뒤 맥락이 잘림, 같은 내용이 상위를 도배하는 문제 등 | |
| 임베딩 | 문서 조각과 질문을 검색에 쓸 벡터로 변환하기 | 표현이 다른 질문과 문서가 잘 연결되지 않는 경우 존재, 색인시 와 질문할 때 호환되는 임베딩 모델을 사용해야 함. |
|
| 1차 검색 | 키워드와 의미로 후보를 넓게 건지기 | 에러코드·고유명사·번호를 못 찾는 문제. | |
| 재정렬 | 후보를 질문 기준으로 다시 줄 세우기 | 정답 문서가 있는데 엉뚱한 게 1등 | |
| 생성 | 고른 조각으로 답 생성 | 문서에 없는 말을 지어내는 경우도 존재. |
파인튜닝과 RAG
파인튜닝은 말 그대로 LLM 모델 자체를 학습하는 방식이라 할 수 있고, RAG는 모델 그 자체가 아니라, LLM이 적절한 답변 생성을 할 수 있도록 참고할 수 있는 관련 자료를 찾아 조정하여 전달하는 방식이라 할 수 있다.
| 프롬프트만 | RAG | 파인튜닝 | |
|---|---|---|---|
| 하는 일 | 지시와 제공된 맥락 전달 | 검색한 외부 자료를 답변 맥락으로 제공 | 예시를 학습시켜 답변 행동이나 형식 등을 조정 |
| 지식이 바뀌면 | 프롬프트를 손으로 수정 | 자료를 다시 색인하고 반영 상태를 확인 | 변경된 학습 데이터로 다시 학습·배포 |
| 환각 | 제공한 자료만 근거로 답하게 하기 어려움 | 출처 정보를 함께 제공하면 근거를 확인하기 쉬움 | 학습 후에도 사실 오류 가능성은 남음 |
| 구축 비용 | 낮음 | 중간 (검색 인프라 ex opensearch ...) | 높음 (데이터셋 + GPU) |
| 잘 맞는 곳 | 요약, 톤 바꾸기 | 사내 규정봇, CS, 자주 바뀌는 정보 | 반복 작업의 응답 방식·형식 조정 |
RAG와 파인튜닝은 어느 하나가 좋고 뛰어나다라기 보다는 각 목적에 따라 잘 맞는 것이 다르다. 최신 문서나 조직별 자료를 찾아 답해야 한다면 RAG가 잘 맞고, 답변 형식이나 특정 작업을 수행하는 방식이 일관되지 않는다면 프롬프트 조정이나 파인튜닝이 더 적절할 수 도 있다. 필요에 따라서는 어느 하나가 아니라 여러 방식을 함께 조합하여 사용하기도 한다. (RAG, 파인튜닝, 프롬프트 그 어느 것도 100% 오류나 환각이 절대 없다고 보장할 수 는 없다.)
RAG 파이프라인 적용 후 답변 성능이 떨어질 때 확인할 사항.
- 정답 조각이 후보에 들어왔나? 없다면 문서 파싱, 청킹, 임베딩, 검색 조건을 차례로 확인.
- 후보에는 있지만 상위에 없나? 검색 결과 병합 방식이나 리랭커 설정 확인.
- 관련 조각이 충분히 전달됐는데도 답이 틀린 경우에는 프롬프트, 답변 생성, 근거 사용 방식 확인.
RAG 파이프라인 구축 시 처음부터 퍼펙트하게 만든다기 보다는 기본적인 구성으로 구현 후, 답변을 확인하고 문제를 파악해가면서 적절한 작업 단계(쿼리 변환, 재생성 질의, 추가 질의 생성, 하이브리드 검색, 리랭킹 등등...)를 추가하는 방법이 좋은 것 같다.(개인적인 생각...)