RAG 검색 기반 생성
학습을 시켜야 우리 데이터를 안다고 생각하기 쉽습니다. 그런데 학습이 바꾸는 것은 주로 말투와 형식이지 지식이 아니고, 문서가 바뀔 때마다 다시 학습시킬 수도 없습니다. RAG 는 학습 대신 검색을 씁니다. 그래서 문서를 고치면 다음 질문부터 바로 반영됩니다.
한 문장으로
RAG 는 모델을 우리 데이터로 다시 학습시키는 것이 아니라, 질문이 올 때마다 관련 문서를 찾아 함께 넣어 주는 방식입니다.
하는 일
- 문서 수집 — 어디에 흩어져 있는 것을 모을지
- 쪼개기 — 긴 문서를 검색되기 좋은 크기로 나누기
- 의미 기반 검색 — 같은 말이 아니어도 뜻이 가까우면 찾기
- 근거 표시 — 어느 문서의 어느 부분을 보고 답했는지
- 권한 분리 — 볼 수 있는 사람에게만 그 문서가 검색되게
- 갱신 — 문서가 바뀌면 검색 대상도 따라 바뀌게
하지 않는 일
- 모델 자체를 바꾸는 일 — 그건 학습이고 다른 접근입니다
- 문서를 쓰는 일 — 없는 내용을 만들어 내지는 않습니다
- 사실 검증 — 문서가 틀렸으면 답도 틀립니다
이웃 개념과 헷갈리는 지점
- 파인튜닝모델을 우리 데이터로 더 학습시키는 것
- 말투와 형식을 맞추는 데 유리하고, 사실을 외우게 하는 데는 불리합니다. 문서가 자주 바뀌면 특히 맞지 않습니다.
- 임베딩글을 의미가 담긴 숫자로 바꾸는 것
- RAG 의 검색이 이 위에서 돕니다. 같은 단어가 아니어도 뜻이 가까우면 찾아지는 이유입니다.
- 컨텍스트 창한 번에 넣을 수 있는 분량
- 문서를 다 넣을 수 없으니 골라 넣는 것이 RAG 입니다. 창이 커져도 다 넣으면 비싸지고 답이 흐려집니다.
- 일반 검색키워드가 일치하는 문서를 찾는 것
- 둘을 섞어 쓰는 경우가 많습니다. 제품명이나 코드처럼 정확히 일치해야 하는 것은 키워드 검색이 더 낫습니다.
언제 필요한가
이럴 때 필요합니다
- 사내 문서가 흩어져 있어 매번 담당자에게 물어야 할 때
- 같은 질문이 반복해서 들어올 때
- 문서가 자주 바뀌어 학습 방식으로는 못 따라갈 때
- 답의 근거를 대야 할 때
아직 아니어도 됩니다
- 문서가 정리돼 있지 않다면 정리가 먼저입니다. 상태가 나쁘면 어떤 방식도 답이 흔들립니다
- 문서가 몇 개뿐이라면 매번 그냥 넣어 주는 편이 단순합니다
- 정답이 정해진 질문만 받는다면 규칙 기반이 더 정확하고 쌉니다
여기서부터는 갈립니다
답의 품질은 모델보다 문서를 어떻게 쪼개고 무엇을 검색 대상으로 삼느냐가 더 많이 좌우합니다. 그리고 그 설정에 일반해가 없어서, 실제로 들어올 질문으로 몇 번 돌려 보고 조정해야 합니다. 문서 상태가 나쁘면 — 표가 이미지로 되어 있거나, 같은 문서의 버전이 여럿이거나, 어느 것이 최신인지 표시가 없으면 — 어떤 방식을 써도 답이 흔들립니다. 그래서 도입 전에 문서를 한 번 훑어보기 전에는 결과를 장담하기 어렵습니다.
자주 묻는 질문
학습은 모델 자체를 바꾸고, RAG 는 질문할 때 자료를 함께 건네줍니다. 문서를 고쳤을 때 학습은 다시 시켜야 하지만 RAG 는 바로 반영됩니다. 사내 문서처럼 자주 바뀌는 것에는 RAG 가 맞습니다.
어떤 모델을 쓰느냐에 따라 다릅니다. 외부 서비스를 쓰면 질문과 함께 문서 일부가 그쪽으로 갑니다. 사내 서버에 모델을 두면 나가지 않는 대신 장비 비용이 듭니다. 다루는 정보에 따라 정하시면 됩니다.
양보다 상태가 중요합니다. 잘 정리된 문서 열 개가 뒤섞인 백 개보다 낫습니다. 특히 어느 것이 최신인지 구분되지 않으면 답이 옛 내용을 말하게 됩니다.
근거를 함께 보여 주게 만드는 것이 가장 실용적입니다. 어느 문서를 보고 답했는지 나오면 사람이 바로 확인할 수 있습니다. 완전히 막는 방법은 아직 없어서, 드러나게 만드는 쪽으로 설계합니다.
됩니다. 검색 단계에서 그 사람이 볼 수 있는 문서만 대상으로 삼으면 됩니다. 다만 설계할 때부터 넣어야 합니다. 나중에 붙이면 이미 답변에 섞여 나간 뒤가 됩니다.
범위가 애매해도 괜찮습니다
지금 상황만 알려 주시면 필요한 범위와 대략의 규모를 짚어 드립니다.