검색 증강 생성 (RAG)
RAG · grounding
한 줄로
검색 증강 생성은 질문과 관련된 대목을 문서 모음에서 찾아 모델의 프롬프트에 넣고, 그것으로 답하게 하는 방식이다. 모델의 가중치는 그대로이고 지식은 요청 시점에 컨텍스트로 도착한다. 그래서 문서를 고치면 다음 답이 곧바로 바뀐다.
RAG 는 두 부분이다. 미리 문서를 청크로 나누고 임베딩으로 바꿔 색인한다. 요청 시점에 질문을 임베딩하고 가장 가까운 청크들을 — 보통 키워드 검색과 함께 — 가져와, 그것만으로 답하고 출처를 인용하라는 지시와 함께 프롬프트에 붙인다.
기업 도입에서 RAG 가 지배적인 이유는 기술이 아니라 운영에 있다. 지식이 우리 문서 저장소에 산다. 문서를 고치면 다음 답이 바뀐다. 재학습도, 지연도 없다. 그리고 검색 시점에 권한을 강제할 수 있어, 사용자가 볼 자격이 없는 대목은 애초에 오지 않는다.
실패 모드는 한 곳에 몰려 있다. RAG 문제의 대부분은 검색 문제다. 순수 벡터 유사도는 청구서 번호·제품 코드·사람 이름 같은 정확한 식별자에 약하고, 그 지점이 키워드 검색이 강한 곳이다. 둘을 함께 돌려 순위를 합치는 하이브리드 검색이 실무 기본값이 된 이유다. 정의와 예외를 갈라놓는 청크 경계, 빠진 메타데이터 필터, 너무 적은 후보 수가 나머지 대부분을 설명한다.
검색과 생성을 «따로» 평가하라. 질문–정답대목 쌍이 필요하다. 최종 답만 보고 판단하는 팀은 어느 쪽을 고쳐야 할지 알 수 없다. 자세한 것은 RAG 는 어떻게 도는가에서 다룬다.
자주 묻는 질문
- RAG 가 파인튜닝보다 나은가?
- 다른 문제를 푼다. RAG 는 모델이 모르는 사실을 공급하고, 파인튜닝은 형식·말투·좁은 기술을 다듬는다. 지식이 없는 것이 문제라면 RAG 다.
- RAG 를 붙였는데 왜 틀리는가?
- 거의 언제나 검색이 엉뚱한 대목을 가져왔기 때문이다. 모델을 탓하기 전에 실제로 무엇이 검색됐는지 확인하라 — 꼼꼼한 사람도 그 대목으로 답할 수 없었다면 모델에게는 기회가 없었다.