ChatGPT와 같은 대규모 언어 모델(LLM)이 외부 문서를 검색하고, 찾아낸 정보를 바탕으로 답변을 생성하도록 하는 메커니즘이 바로 '검색 증강 생성(RAG)'입니다. Hugging Face와 Databricks에서 근무한 경력이 있는 AI 엔지니어 라파엘 피에르 씨가 RAG를 단순한 전문 검색에서 시작해 단계적으로 고도화하는 6가지 방법을 소개하고 있습니다. 6 RAG Architectures — and How to Avoid Over-Engineeringhttps://www.lighthousenewsletter.com/p/rag-is-simpler-than-you-think
LLM이 사내 매뉴얼이나 학습 이후에 공개된 최신 정보 등을 미리 알고 있는 것은 아닙니다. 그래서 질문과 관련된 문서를 검색하고, 찾은 내용을 LLM에 전달하여 답변하게 만드는 것이 RAG입니다. RAG를 구축하는 방법은 여러 가지가 있기 때문에, 피에르 씨는 처음부터 복잡한 시스템을 준비하기보다 실제 검색 결과나 이용 상황을 보면서 필요에 따라 구성을 고도화하는 방법을 권장하고 있습니다. 1: 전문 검색 첫 번째는 '전문 검색'입니다. 입력된 단어를 문서 내에서 찾는 일반적인 검색 방법으로, 제품명이나 모델 번호, 에러 코드 등 검색하고자 하는 단어가 명확한 경우에 적합합니다. 특별한 AI용 데이터베이스를 준비할 필요도 없습니다.
2: 쿼리 리라이트 전문 검색만으로는 '차'와 '자동차'처럼 의미가 가깝지만 다른 단어를 잘 연결하지 못하는 경우가 있습니다. 그래서 두 번째 방법에서는 LLM이 검색어를 재작성하도록 합니다. "프로그램을 빠르게 하고 싶다"라는 질문을 "고속화", "최적화" 등 검색하기 쉬운 단어로 변환하여 기존 전문 검색을 활용하기 쉽게 만듭니다. 3: 하이브리드 검색 세 번째는 전문 검색과 의미 검색을 조합하는 '하이브리드 검색'입니다. 먼저 문자 일치로 후보를 추린 후, 문장 간 의미의 유사성을 조사하여 순위를 다시 매깁니다. 문장의 의미를 숫자 집합으로 변환하는 '임베딩'이라는 기술을 사용함으로써, 표현이 다르더라도 내용이 유사한 문서를 찾기 쉬워집니다. 의미 검색을 도입하면, 다음에 고민해야 할 점은 '문서를 언제 임베딩으로 변환할 것인가'입니다. 4: 온디맨드 임베딩 모든 문서를 미리 임베딩으로 변환해 두는 방법도 있지만, 뉴스나 문의 내역처럼 업데이트가 잦은 데이터는 사전 준비나 갱신에 드는 번거로움이 커집니다. 그래서 검색을 통해 발견된 후보만을 그 자리에서 즉시 임베딩으로 변환하는 것이 '온디맨드 임베딩'입니다. 검색 시의 처리량은 늘어나지만, 사전 준비의 부담을 크게 줄일 수 있습니다. 5: 핫/콜드 계층 다섯 번째는 자주 검색되는 문서만 미리 처리해 두는 방법입니다. 이용 빈도가 높은 문서는 미리 임베딩으로 변환해 두고, 자주 사용되지 않는 문서는 필요할 때만 임베딩으로 변환합니다. 검색 속도를 유지하면서 사전 처리의 번거로움을 줄이기 위한 중간적인 구성입니다. 6: 사전 임베딩 여섯 번째는 모든 문서를 미리 임베딩으로 변환하여 '벡터 데이터베이스'라고 불리는 시스템에 저장하는 방법입니다. 대량의 문서에서 의미가 유사한 정보를 빠르게 찾을 수 있어, 검색 횟수가 매우 많고 문서의 업데이트가 적은 서비스에 적합합니다. 반면 문서가 업데이트되면 해당 부분의 재처리가 필요해지며, 임베딩 모델을 변경할 때는 대량의 문서를 다시 처리해야 하는 경우가 있습니다.
즉, RAG는 처음부터 벡터 데이터베이스를 준비하지 않으면 성립하지 않는 구조가 아니라, 전문 검색부터 시작해 필요에 따라 쿼리 리라이트나 의미 검색을 추가하는 것이 가능하다는 뜻입니다. 임베딩 방법도 데이터의 갱신 빈도나 이용 규모에 맞춰 선택할 수 있습니다. 피에르 씨는 '80:20의 법칙'에 비유하며, RAG 시스템의 60%는 전문 검색과 쿼리 재작성으로 충분하고, 25%는 온디맨드 임베딩 등을 사용한 하이브리드 구성, 10%는 전체 문서의 사전 임베딩, 남은 5%만이 독자적인 고도의 구조를 필요로 한다는 기준을 제시하고 있습니다. 이러한 비율은 조사 결과가 아니라 피에르 씨의 경험에 바탕을 둔 것이지만, RAG를 구축할 때는 필요 이상으로 복잡한 구조를 처음부터 준비할 필요는 없다고 합니다. 피에르 씨는 "60%의 문제에 대해 5%의 케이스에서만 필요로 하는 해결책을 만드는 사람이 되어서는 안 됩니다"라고 말하고 있습니다.
원문 보기 | 출처: Gigazine