RAG: 검색, 증강, 생성

LLM의 한계점에 대한 해결 방법

1. PEFT(Parameter-Efficient Fine Tuning): 일부 파라미터만 튜닝 (0.1~0.01퍼센트 정도 극히 적은 파라미터만을 학습시켜 파인튜닝을 함)
   • P-Tuning: 입력 임베딩 자체를 튜닝
   • LoRA(Low-Rank Adaptation): Pre-trained model의 일부 Dense Layer의 가중치(Adapter)를 학습, 학습 종료 후 원본 모델과 결합하는 방식으로 파인튜닝
2. MOE(Mixture of Experts): 다양한 도메인 지식을 각 전문가 레이어로 라우팅 하는 기법 - 필요한 도메인만 활성화할 수 있음
3. 프롬프트 증강: 질문에 따른 적절한 데이터를 프롬프트에 자동으로 추가

 

프롬프트 증강을 하는 RAG

RAG: 검색을 통해 LLM의 생성 과정을 증강하는 기법 / 시스템이 자동으로 적절한 정보를 찾아 사용자가 입력한 프롬프트에 추가하는 것

- Retrieve(검색) Agmented(증강) Generation(생성)

 

RAG의 진행과정

1. 사전에 정보를 담고 있는 문서를 일정 크기(Chunk)로 나눠서 Vector(워드 임베딩해서 만든 벡터) DB에 저장. 글자를 쪼개서 벡터화한다 (의미 담고 있는 벡터값으로 바꾼다). 
2. 사용자의 입력과 유사한 K개의 벡터를 검색
3. 사용자의 입력 + 검색된 문서 => 증강된 프롬프트를 LLM에 입력
4. LLM은 검색된 문서 정보를 바탕으로 상대적으로 더 정확한 답변을 생성할 수 있게 됨
5. 유지보수도 용이한데, LLM 모델만 바꿔주면 성능 향상이 가능하다.

*참고: 스칼라 ->  벡터 ->  행렬 -> 텐서 순으로 모이면서 확장됨

 

문제

• K개의 검색 결과가 많이 나오면 결과값이 너무 많이 나오게 될 수 있음
• 그렇다고 검색을 조금만 할 수는 없음
• 그리고 검색을 빨리 하는 것 자체도 중요

 

정보 검색(Retrieval)

: DB, 인터넷 또는 정보 저장소에서 관련 정보를 찾아내는 과정

 

초기 검색 알고리즘

: 역색인을 활용한 검색. 다양한 알고리즘을 통해 계산한 유사도 점수를 활용한 검색

• TF-IDF(Term Frequency - Inverse Document Frequency): 단어가 문서에서 얼마나 중요한지 계산하는 지표.
  • 단어의 빈도와(TF: 지표1), 자주 등장하되 문서마다 등장하는 것은 중요하지 않다고 두는(IDF: 지표 2) 알고리즘. 지표 2개를 곱해서 표현한다. 
  • 모든 문서에서 자주 나오지 않고, 한 문서에서 빈도수가 높은 희소한 단어는 점수가 높게 배치된다
  • 단어 빈도 지표여서, 단어가 아닌라 문장이나 문서에 담긴 의미를 고려하기 어렵다는 한계
• BM25: IDF(희소한 단어)에 더 높은 점수를 부여한 방식

임베딩(=벡터 변환)

: 벡터 임베딩을 활용해서, 각 문서를 벡터로 임베딩 하고, 그 벡터의 유사도를 평가. 

• AI는 자연어를 있는 그대로 입력 받는 것이 아니라, 알고리즘을 따라 정해진 크기로 벡터화된 정보를 입력받음
• 다국어 환경에서는 큰 벡터 크기가 복잡한 언어 패턴을 학습하는데 유리함
• 벡터 크기와 성능은 대체로 비례함

https://www.elastic.co/kr/what-is/retrieval-augmented-generation

• 벡터화 순서: 원본 문서 > 텍스트 추출 > 텍스트 분할 > 임베딩 > 벡터화한 결과를 모아서 Vector DB를 만듦
• 기존 문서를 임베딩 해서 벡터 DB로 만들 때(이 결과가 Vector DB)와 사용자 질문을 임베딩할 때 모두 같은 임베딩 서비스를 사용해야 함

관련한 문제

• 질문을 던졌는데 DB에 정답이 될만한 데이터가 없으면 -> 질문을 해소하지 못하는 답변이 나올 수 있음
• 문서가 너무 많아도 벡터 DB 구축에 비용이 많이 듦

 

복합 RAG 구조 및 콘텍스트 최적화

회수(검색) 단계 문제

• 사용자 프롬프트에서 검색 힌트를 찾기 어려움
• 유사도 검색 방식에서 완벽하지 않다 보니 검색 결과가 잘 나오지 않음
• 검색 횟수 문제

해결 방법 1: Advanced RAG Pre-Retrieval 전략

사용자의 쿼리로 벡터 DB에서 적절한 데이터를 회수하는 과정을 개선하는 것에 초점

• 쿼리 변환(Query Transformation)
  • 쿼리 재작성(Rewriting): 사용자 질문을 재작성하는 LLM을 넣어버림(Rewriter LLM 모델). 욕설 등 검색 방해 요소 제거. 검색 엔진 최적화된 형태의 쿼리로 재작성, 키워드 뽑아서 다시 작성
  • 쿼리 분해(Decomposition): 질문을 여러 개의 간단한 하위 질문으로 나누는 전략. 다양한 문서가 검색될 수 있도록 함
  • 쿼리 확장(Expansion): 표준어로 물어봤을 때 사투리, 외국어 등을 섞어서 새로운 문장을 만든 후, 서로 다른 N개의 문장으로 검색. 검색된 Chunk들은 회수 후 중복 제거
  • HyDE(Hypothetical Document Embedding): 질문으로 답변을 검색하는 것 자체가 논리적 모순. 모델에 질문이 들어오면 예비 답변(가설 = 뇌피셜)을 여러 개 생성. 이 가짜 답변과 실제 문서를 비교해서, 키워드는 다를 수 있는데(맛집 상호명) 그래도 문장 구성은 비슷하다면, 그때 실제 답변 문서를 선택하는 것

  • 

    https://medium.com/ai-insights-cobet/power-of-hypothetical-document-embeddings-an-in-depth-exploration-of-hyde-92601a335e5f

  • 보통은 4개를 조합해서 사용함
• 유사도 검색 방식 조정: Dot Product, Manhattan, Cosine Distance, Squared Euclidean 등 방법이 있음
• Hybrid Searching: Sparse Retrieval(등장 단어 빈도 기반 검색)과 Dense Retrieval(생성된 임베딩을 활용하여 검색, 쿼리와 문서의 의미를 벡터 공간에 매핑하여 유사도 측정)을 결합하여 정보 검색, 핵심 단어 일치 여부 확인 및 의미 기반 검색 결합 가

쿼리의 품질은 이후 Post-Retrieval, Generation 결과와 직결됨

 

해결 방법 2: Advanced RAG Pre-Retrieval 전략

• 콘텍스트 필터링(Context Filtering): 유사도 기반 필터링으로 일반적으로 NLI 모델을 활용해 관련 없는 정보 필터링
• 컨텍스트 압축(Context Compression): 핵심 정보를 유지하면서 검색된 문서의 크기를 줄임
• Reranking: 가장 그럴싸한 문서부터 가장 적절하지 않은 것으로 판단되는 문서까지 문서 관련성을 재정렬. 결과의 우선순위를 정해서 답변하기 위함.
  • 문제는 사람이 정렬하는 것이 아니라 모델이 정렬하는 것이기 때문에 불확실성이 있음. 
  • Lost in the middle 문제: 정답 문장이 글 내 위치에 따라 실제로 답변에 반영되는 정도가 상이했음

    

    https://medium.com/@carolzhu/lost-in-the-middle-how-language-models-use-long-contexts-2891830f8000

해결방법 3: 검색 횟수와 검색 범위 조절

• Single-hop: 하나의 정보 조각으로 답변 가능
• Multi-hop RAG: 여러 개의 문서를 검색하고, 이를 기반으로 추론을 통해 사용자의 질문에 답하는 RAG
• Hierarchical RAG: 정보를 계층적으로 구조화해 검색 및 답변의 정확성과 맥락성을 높이는 RAG. 그런데 간단한 질문에도 이렇게 구축해 두면 괜히 복잡하게 여러 번 검색되는 문제가 있음

 

지금까지 LLM의 한계를 보완하는 다양한 기법들과 RAG 시스템의 고도화 전략을 살펴보았습니다.