Bedrock RAG의 정확도를 늘리는 방법

개요

---

해당 글에서는 AWS Bedrock에 RAG(검색 증강 생성) 아키텍처를 적용할 때, 사용자들이 만족할만한 수준의 응답을 얻기 위해 조치할 수 있는 방법들을 기술합니다.

 

RAG(검색 증강 생성) 아키텍처 상에서, 정확도를 높이는 방법

---

 

콘텐츠 타입에 맞추어 문자열을 가공합니다.

• HTML의 경우는 내부 유틸리티 서비스를 통해 정제된 텍스트 본문을 파싱합니다.
• 페이지 정보(PDF), 영상 시간(YouTube)의 경우에는 해당 콘텐츠의 위치를 보존하기 위해 별도의 포맷으로 정제합니다.

정제된 텍스트는 정해진 사이즈에 따라 청크로 쪼개집니다. 청크 사이즈의 단위는 메인 LLM 모델의 토큰입니다. 사실 이렇게 단순히 순서대로 조각내는 방법에는 개선의 여지가 많아 보입니다. 이론적으로 이상적인 청킹은 청크 간에는 의미가 독립적이고, 청크 내에서는 의미의 응집도가 높은 상태입니다. 하지만 이를 위해서는 본문을 해석하고 해체하는 작업이 수반되어야 합니다. 역시 모든 것은 트레이드 오프 아니겠습니까. 성능이 얼마나 올라갈지, 해석 비용이 얼마나 될지를 알아야 합니다. 후자는 바로 알 수 있지만, 성능에 대해서는 결국 청킹 관련 실험과 평가가 선행되어야 합니다.

개발 당시에는 평가 시스템이 없어 눈으로만 품질을 판단해야했고, 선행작업에 드는 처리 과정의 효용을 따지기가 어려웠습니다. 이에 아직까지는 정해진 청크 사이즈대로 본문 순서에 따라 조각내고 있습니다만, 향후 RAG 평가 시스템을 통해 다양한 청킹 방법을 실험할 예정입니다.

 

비용은 토큰 수로 측정하기 때문에 청크 사이즈와는 상관 없이 원문의 길이에만 영향을 받습니다.

만약 청크 사이즈가 작다면 어떻게 될까요?

아무래도 문장과 같이 세부 단위로 임베딩 검색이 가능해지고, 임베딩이 표현하는 텍스트도 적어지며 노이즈도 적어지겠지만 저장 비용과 검색 비용이 증가합니다.

실제로 임베딩의 차원이 1000 차원 이상으로 큰 편이기 때문에 발생하는 저장 비용을 무시할 수 없었습니다. 그렇다고 무작정 청크 사이즈가 늘어난다면, 검색 비용과 저장 비용은 줄지만, 벡터 서치의 효용이 떨어지겠다고 판단했습니다.

결국 저장, 검색 비용과 벡터 서치 정확도 간의 트레이드 오프이고 이 역시 적절한 조합을 찾기 위해서 retrieval에 대한 평가가 필요하다는 것을 알 수 있었습니다.

청크 사이즈 결정에 숨은 복병은 따로 있었는데요, 바로 Embedding API의 RPM 제한이었습니다. 청크 사이즈를 작게 자르니 임베딩 생성 요청 수가 빠르게 소진되며 요청이 막혔습니다. 현재는 문제가 발생하지 않는 수준에서 청크 사이즈를 키워두고, 동시성을 조종하는 등 적정선을 찾아가고 있습니다.

결국 청크 사이즈를 결정하는 일은 서버 퍼포먼스, 저장 비용, 검색 비용 그리고 벡터 서칭 정확도까지 모두 고려해야 했습니다.

 

키워드 추출

유저의 질문이 본문 내용 일부를 정확히 기술하는 경우에는 텀 매칭이 잘 작동합니다.

하지만 대부분 유저가 하는 질문은 모호한 경우가 많고, 넓은 범위의 의미를 묻는 경우가 많습니다.

따라서 텀 매칭이 잘 동작하지 않았고 텀 매칭에 쓸 키워드를 LLM으로 뽑아내는 과정이 필요했습니다.

본문의 일부를 fetch 하여 프롬프트에 맥락을 전달하고, 유저의 질문 의도를 파악하여 검색에 쓰일 키워드를 추출하는 로직을 ML 플래닛의 도움을 받아 구현했습니다.

이렇게 뽑힌 키워드는 search 요청에서 사용됩니다.

실제 운영하면서 키워드 추출 정책을 계속해서 수정했는데요,

그중에서도 글의 메인 키워드가 다량으로 추출되는 경우, 세부 키워드가 포함된 청크가 검색이 잘되지 않는 문제가 있었습니다.

그 때문에 키워드 추출의 개수를 1~2개로 줄이고, 다른 범위의 키워드를 생성하지 못하도록 유저 질의에 포함된 키워드와 동의어만 추출하도록 변경했습니다.

이후에 기존에 잘 잡아내지 못했던 개념 질문에 대답하는 것을 확인할 수 있었습니다.

스크립트 내 코사인 유사도와 텀 매칭 스코어를 휴리스틱 하게 조합하여 찾는 것이 제일 원하는 대답을 찾는데 도움이 되었습니다.

 

어떤 메트릭으로 평가하여 LLM을 사용할지에 대하여 Ragas라는 오픈소스 평가 프레임워크를 참고해 볼 수 있습니다. 아래는 Ragas에서 제시된 메트릭입니다.

• faithfulness: 할루시네이션 카운터 메트릭, retrieval에 의해 제공되는 맥락(context)에서 벗어난 발언을 하지 않는지 검증
  1. 생성된 답변을 명제로 분해(by LLM)
  2. 분해된 명제가 제공된 맥락과 일치하는 지 검사 (by LLM)
• answer relevancy: 답변과 질문이 얼마나 연관성이 있는지 체크 (by LLM)
• context relevancy: retrieval로 가져오는 맥락에서 ground truth의 비중 (signal-to-noise)
• context recall: retrieval로 가져오는 맥락에서 ground truth를 얼마나 가져올 수 있는지

평가가 마련된 이후에는 여러 실험을 통해 최적의 청크, 임베딩 조합을 찾는 것도 가능하며, 프롬프트 변경에 대한 품질 관리도 가능해질 것으로 보입니다

 

Hierarchical Search

낮은 단계의 청크들에 있는 노이즈에 임베딩 매칭이 되는 것이 아닌, 상위 청크에 응집된 중요 정보가 모인 청크에서 임베딩을 통한 의미 매칭이 되며 중요 정보를 더 정확하게 가져갈 수 있다고 주장하는 방법론입니다. 

정확하게 동작할지는 미지수이다.

 

LLM에서 RAG 를 이용한 문서 검색을 할때 Chunk 전략도 중요하지만, Chunk를 어떻게 임베딩 하느냐가 중요합니다. 리서치를 해보니 우리가 많이 사용하는 openai chatgpt 임베딩 API는 전체 임베딩 레더 보드에서 20위권이네요...
적절한 임베딩 API를 찾는 방법과 임베딩 API의 순위 정보를 공유합니다

영문/중문 임베딩 순위 → https://huggingface.co/spaces/mteb/leaderboard

한글 임베딩 순위 → https://project-miracl.github.io/ 

https://eval.ai/web/challenges/challenge-page/1881/leaderboard/4450

 

Cohere Multilingual embedding v3의 경우, ko(한국어) 점수가 대략 65점 정도로 준수한 편이다.

검색 증강 생성의 문제점과 한계

 

RAG는 상당한 이점을 제공하지만 다음과 같은 몇 가지 문제점과 한계도 있습니다.

• RAG는 외부 지식에 의존합니다. 검색된 정보가 올바르지 않으면 부정확한 결과가 나올 수 있습니다.
• RAG의 검색 구성 요소에는 대규모 지식 기반이나 웹을 검색하는 것이 포함됩니다. 이는 컴퓨팅 측면에서 비용이 많이 들고 느릴 수 있지만, 여전히 미세 조정보다는 빠르고 저렴합니다.
• 검색 및 생성 구성 요소를 원활하게 통합하려면 신중한 설계와 최적화가 필요하며, 이에 따라 훈련 및 배포에 잠재적인 어려움이 발생할 수 있습니다.
• 외부 소스에서 정보를 검색하면 민감한 데이터를 다룰 때 개인정보 보호 문제가 발생할 수 있습니다. 개인정보 보호 및 규정 준수 요구 사항을 준수하는 것으로 인해 RAG가 액세스할 수 있는 소스가 제한될 수도 있습니다. 그러나 이 문제는 특정 역할에 액세스 및 보안 권한을 부여할 수 있는 문서 수준 액세스를 통해 해결할 수 있습니다.
• RAG는 사실적 정확성을 기반으로 합니다. 상상력이 풍부하거나 허구적인 콘텐츠를 생성하는 데 어려움을 겪을 수 있으며, 이로 인해 창의적인 콘텐츠 생성에 사용이 제한됩니다.

 

참고 자료

---

Multi-RAG와 Multi-Region LLM로 한국어 Chatbot 만들기

https://aws.amazon.com/ko/blogs/tech/multi-rag-and-multi-region-llm-for-chatbot/

나만의 정보탐색 파트너, 브라우징 코파일럿 RAG 도입기

https://blog.getliner.com/%eb%82%98%eb%a7%8c%ec%9d%98-%ec%a0%95%eb%b3%b4%ed%83%90%ec%83%89-%ed%8c%8c%ed%8a%b8%eb%84%88-%eb%b8%8c%eb%9d%bc%ec%9a%b0%ec%a7%95-%ec%bd%94%ed%8c%8c%ec%9d%bc%eb%9f%bf-rag-%eb%8f%84%ec%9e%85%ea%b8%b0/

기업용 LLM+RAG 챗봇 도입 가이드 :: 사전 준비부터 실제 적용 사례까지 총정리

https://www.skelterlabs.com/blog/enterprise-llm-and-rag

검색 증강 생성(RAG)이란?

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

ChatGPT에 텍스트 검색을 통합하는 RAG와 벡터 데이터 베이스

https://bcho.tistory.com/1406

Cohere Embed v3 소개

https://txt.cohere.com/introducing-embed-v3/