검색 증강 생성(RAG), 제1원리에서 출발하기

검색 증강 생성(RAG)은 보통 여러 제품으로 이루어진 파이프라인으로 소개됩니다. 임베딩 모델, 벡터 데이터베이스, 리트리버(retriever), 제너레이터(generator)처럼요. 그러나 이런 식의 설명은 본말이 전도된 것입니다. RAG는 하나의 아이디어이고, 그 도구들은 그것을 구현하는 한 가지 방식일 뿐입니다. 그 아이디어란 이렇습니다. 모델이 답하기 전에, 답의 근거로 삼을 구체적인 자료를 건네주라. 나머지는 전부 엔지니어링입니다.

이 용어는 2020년 Lewis와 동료들이 발표한 논문에서 나왔습니다. 이 논문은 리트리버와 제너레이터를 결합해, 모델이 가중치에 암기해 둔 내용에만 의존하는 대신 외부 구절을 끌어올 수 있게 했습니다. 그때의 동기가 지금의 동기이며, 이를 제1원리에서부터 이해해 두면 어떤 특정 도구보다도 오래 살아남는 통찰이 됩니다.

RAG가 해결하는 문제

언어 모델은 특정 시점에 동결되어 가중치에 녹아든 학습 데이터에 담긴 것만 압니다. 여기서 두 가지 한계가 생깁니다.

• 모델은 당신의 비공개 정보나 최신 정보를 알 수 없습니다. 회사 문서, 지난주 릴리스 노트, 특정 PDF의 내용. 그 어느 것도 모델 안에 들어 있지 않습니다.
• 가중치로부터의 회상은 손실이 있습니다. 모델 "안에" 있는 것조차도 정확한 세부 사항이 틀리게 나올 수 있습니다. 모델은 무언가를 찾아보는 게 아니라 압축된 기억으로부터 재구성하는 것이기 때문입니다.

RAG는 질문 자체를 "모델은 무엇을 기억하는가?"에서 "지금 이 순간 모델 앞에 무엇을 놓아줄 수 있는가?"로 바꿔 두 한계를 모두 해결합니다. 기억에서 증거로의 이 전환, 그것이 핵심의 전부입니다.

세 단계로 본 작동 원리

본질적으로 RAG는 세 가지 동작입니다.

1. 색인(Index). 원본 자료를 여러 구절로 쪼개어 검색 가능한 형태로 저장합니다. 대부분의 시스템은 각 구절을 임베딩 — 비슷한 의미끼리 가까이 배치하는 벡터 — 으로 변환해 그 벡터들을 저장하는 방식으로 이를 처리합니다.
2. 검색(Retrieve). 질문이 들어오면, 그와 가장 관련 있는 구절을 찾습니다. 임베딩을 쓰는 경우, 질문을 벡터로 바꾼 뒤 가장 가까운 구절들을 가져온다는 뜻입니다.
3. 생성(Generate). 검색된 구절을 질문과 함께 모델의 컨텍스트에 넣고, 그 자료를 사용해 답하도록 요청합니다.

이것이 전체 흐름입니다. 답은 여전히 모델이 작성하지만, 이제는 기억에서 회상하는 대신 제공된 증거를 읽으며 작성합니다. RAG에서 정교해 보이는 모든 것은 이 세 단계 중 하나를 다듬은 것입니다.

왜 임베딩인가, 그리고 그것이 왜 마법이 아닌가

임베딩을 쓰면 정확한 단어가 아니라 의미로 검색할 수 있습니다. 그래서 "휴무"에 관한 질문이 공유 키워드가 전혀 없어도 "휴가 정책"에 관한 구절을 가져올 수 있습니다. 이건 정말로 유용하며, 의미 기반 검색이 대부분의 RAG 시스템을 떠받치는 이유이기도 합니다. 다만 솔직하게 짚어야 할 두 가지 단서가 있습니다.

• 의미 기반 검색은 정확 검색이 아닙니다. 제품 코드, 특정 조항 번호, 오류 문자열 같은 정밀한 식별자에 대해서는 키워드 검색이 임베딩을 능가하는 경우가 많습니다. 견고한 시스템 상당수는 둘을 결합하며, 이를 보통 하이브리드 검색이라고 부릅니다.
• 검색 품질이 그 아래 모든 것의 상한을 정합니다. 2단계가 잘못된 구절을 반환하면, 모델은 잘못된 자료로 답하면서도 똑같이 자신만만하게 들립니다. 이것이 RAG에 관한 가장 중요한 사실이며, 동시에 데모가 감추는 바로 그 사실입니다.

청킹(Chunking): 품질을 좌우하는, 화려할 것 없는 결정

문서를 어떻게 구절로 쪼개는가가 검색이 얼마나 잘 작동하는지를 조용히 결정합니다. 너무 긴 청크는 관련성을 희석합니다. 유용한 한 문장이 무관한 문장들 사이에 묻히고, 임베딩은 너무 많은 아이디어의 평균이 되어 버립니다. 너무 짧은 청크는 그것을 의미 있게 만드는 맥락을 잃습니다. 변치 않는 조언은 자연스러운 경계를 따라 청킹하라 는 것입니다. 임의의 글자 수에서 자르는 대신 섹션, 단락, 논리적 단위를 따르라는 것이죠. 좋은 청킹은 지루한 작업이지만, 더 화려한 모델로 갈아 끼우는 것보다 더 큰 보상을 줍니다.

좋은 RAG가 실제로 요구하는 것

순진한 버전 — 전부 임베딩하고, 상위 몇 개를 가져와, 욱여넣는 방식 — 은 데모에서는 작동하지만 운영 환경에서는 실망을 안깁니다. 그것을 실제로 작동하게 만드는 요소들은 이렇습니다.

• 합리적인 청킹, 위에서 말한 대로입니다.
• 충분하되 지나치지 않은 컨텍스트. 구절을 더 많이 검색해 오는 것이 늘 좋은 건 아닙니다. 무관한 구절은 모델을 산만하게 하고, 유용한 구절을 주의(attention) 밖으로 밀어냅니다. 최적점이 존재하며, 그것은 보통 사람들이 기대하는 것보다 작습니다.
• 근거 기반 지시(grounding instructions). 제공된 자료에서만 답하고, 자료에 답이 없으면 그렇다고 분명히 말하라고 모델에 지시하세요. 이것이 검색을 자신만만한 추측이 아니라 신뢰할 만한 답으로 바꿔 줍니다.
• 출처 제시. 어떤 구절이 사용되었는지 함께 반환하면 사람이 답을 검증할 수 있습니다. 이는 위험이 큰 모든 작업에 필수적이며, 그 외 어디서든 조용히 신뢰를 쌓는 장치이기도 합니다.

당신의 RAG가 쓸 만한지 가늠하는 법

대부분의 실패가 검색 실패이므로, 검색을 생성과 분리해서 평가하세요. 실제 사례에 대해 던질 두 가지 질문이 있습니다.

1. 애초에 알맞은 구절이 검색되었는가? 검색된 집합 안에 답이 없다면, 아무리 영리한 프롬프트도 생성 단계를 구해 주지 못합니다.
2. 알맞은 구절이 주어졌을 때, 모델이 그것을 충실히 사용했는가? 검색은 좋았는데 답이 엇나갔다면, 문제는 검색이 아니라 근거 기반(grounding)에 있습니다.

평가를 이렇게 나누면 어느 쪽 절반을 고쳐야 하는지 알 수 있습니다. 둘을 뭉뚱그리면 "틀렸다"는 것밖에 알 수 없고, 이는 실행으로 옮길 수 없는 정보입니다.

RAG가 고쳐 주지 않는 것

RAG는 답을 제공된 텍스트에 근거하게 합니다. 그것이 모델을 더 잘 추론하게 만들어 주지는 않으며, 진실을 보장하지도 않습니다. 원본 문서가 틀렸거나 오래된 것이라면, 답은 정확히 똑같은 어조로 자신만만하게 틀릴 것입니다. 또한 RAG는 움직이는 부품을 추가합니다. 색인 단계, 검색 단계, 그리고 그것들 고유의 실패 양상까지 감시해야 합니다. RAG는 답이 반드시 구체적이거나, 변하거나, 비공개인 정보를 반영해야 할 때 알맞은 도구입니다. 모델이 이미 충분히 알고 있고 그저 더 나은 프롬프트만 필요한 경우라면 과한 선택입니다.

RAG는 어디로 향하는가

RAG의 최전선은 대부분 검색을 더 영리하게 만드는 일에 관한 것입니다. 언제 검색할지 결정하기, 여러 차례에 걸쳐 검색하기, 모델이 직접 검색 쿼리를 던지게 하기, 결과가 제너레이터에 도달하기 전에 재정렬(re-rank)하기 등이죠. 이것들은 역량과 복잡성을 똑같은 정도로 더합니다. 제1원리의 관점은 그 모든 것 아래에서 여전히 유효합니다. 전부 모델이 답하기 전에 더 나은 자료를 그 앞에 놓아주는 방법들이니까요.

정리

제품 스택은 잠시 잊으세요. RAG는 모델이 답하기 전에 알맞은 자료를 읽게 하는 규율입니다. 임베딩과 벡터 저장소는 널리 쓰이는 구현일 뿐, 본질이 아닙니다. 검색을 제대로 하고, 청킹을 정성껏 하고, 근거에 머물도록 모델에 지시하세요. 그러면 RAG는 기억으로부터 추측하던 모델을, 증거로부터 — 그것도 직접 확인할 수 있는 출처와 함께 — 답하는 모델로 바꿔 줍니다.