AutoRAG 개발자님 인터뷰 정리

본 글은 Teddynote x AutoRag 제작자님 인터뷰 유튜브 영상을 보고 정리한 내용입니다.
(직접 영상을 보면서 작성한 내용이라 틀린 부분이 있을 수도 있으니, 자세한 것은 영상을 참고 바랍니다.)

 

추가로, 직접 AutoRAG 튜토리얼과 개인 데이터셋에 사용한 가이드도 추후 작성해 보도록 하겠습니다! (중간중간 겪었던 에러들도)

0. AutoRAG 필요성

OpenAI에서 공개한 결과에 따르면, RAG를 이용할 때 단순하게 cosine similarity만을 사용하는 것이 아니라 다양한 모듈을 이용하였을 때 성능이 향상되었음.

그러나 모든 문서에 성능이 뛰어난 RAG모듈은 없다 ==>각 문서마다 최적의 RAG 모듈이 다름.
ex) 금융문서와 법률문서

RAG 모듈의 수가 너무나도 다양하기 때문에 모든 것을 테스트하기가 힘듦. -> 이를 위해 AutoRAG를 만듦

Autorag는 수많은 실험을 효율적으로 편하게 할 수 있도록 자동화한 툴

• yaml 파일 설정만으로 손쉽게 여러 모듈을 테스트할 수 있다.
• 평가용 데이터셋을 자동으로 생성할 수 있다.
• 결과로 나온 최적의 파이프라인을 api서버와 streamlit 웹으로 쉽게 사용할 수 있다.

Q. baseline으로 삼기에 어떤 retriever이 좋은가?
A. 경험상으로는 BM25를 한 번쯤을 써보는 것이 좋다.(키워드기반), Llama index에 있는 BM25는 한국어에는 잘 안되는 구조.
한국어 형태소 분석기를 사용하면 가끔은 OpenAI의 embedding을 이용한 결과보다도 잘되는 경우가 있음.

BM25란, 주어진 쿼리에 대한 문서와의 연관성을 평가하는 랭킹 함수. Elasitc search에서도 사용 중.
문서 내 특정 단어의 빈도수와 문서 집합 전체에서 그 단어가 얼마나 일반적인지를 고려하여 관련성을 계산(TF-IDF의 개선)

Q. 한국어를 잘하기 위해서는 한국어를 잘하는 임베딩 모델이 필요한지 아니면 한국어여도 영어로 임베딩만 잘되면 되는 것인지?
A. 필요하다

1. RAG 평가 방법

크게 rag는 질문 -> 단락 -> 생성의 단계로 이루어짐.

단락이 잘 retrieve 되었는가 + 답변이 잘 생성되었는가

AutoRAG에서는 각 단락에 대한 id를 매겨놓고 정답 단락(ground truth)에 retrieve 된 단락이 포함되었는지를 판단하는 방식

좋은 RAG 평가 데이터를 만드는 방법

• 정말 자동화하는 것은 거의 불가능
• 가장 좋은 방법은 실제 유저의 데이터를 활용
• 도메인 전문가가 직접 만드는 방법
• LLM이 만들고 사람이 검수하는 방법

평가데이터셋을 만들 때는 가장 좋은 모델을 써서 만들어야 함.
-> 그렇게까지 많이 만들지 않아도 됨. 질문 100개 정도를 만듦.(작지만 고품질로 만드는 것이 중요)

2. Retreiveal Metrics

--> 각 메트릭별 자세한 설명 참조 link

F1 score

Recall

실제 정답 중 맞힌 개수
-> 어떤 질문에 대답하기 위한 정보가 retrieve 된 context에 포함되어있어야 하기 때문에 일반적으로 RAG에서는 precision보다 중요함.
= 즉 정답과 유사성 있는 정보를 가져와야 함.

Precision

뽑은 것 중에 몇 개 맞혔는지
-> precision은 환각현상이 존재할 때 중요함. 꼭 필요한 정보가 한두 개쯤은 누락돼도, 환각현상이 있으면 안 되는 도메인 등에 유용한 지표(금융, 법률) 차라리 모르는 게 나을 때
-> precision을 올리기 위해서는 Passage Filter단계에서 유사도가 낮아지는 것을 없앰. (recall이 낮아지고 precsion이 높음)

NDCG

순서를 고려하는 지표, 직관적으로 이해하기는 어렵지만 모듈 간의 성능을 비교하는데 유용함

mAP

순서를 고려하는 지표, mAP가 0.2이면 평균적으로 5개의 단락을 retrieve 하면 정답이 포함되어 있다는 뜻

mRR

순서를 고려하는 지표, 같은 뜻을 가진 단락이 여러 개 있을 때 유용

3. Generation Metrics

모든 LLM을 이용하여 생성한 답변들에 대한 평가 방식

N-gram Based metrcis

전통적인 NLP 지표이며, 매우 싸고 빠르다. 그러나 긴 답변에 대해서는 정확하지 않고 제대로 활용하기 위해서는 많은 GT가 필요함.
ex) METEOR, BLEU, ROUGE

LM-based metrics

빠르고 싸며, BERT 모델을 이용하여 의미론적으로 얼마나 비슷한지를 측정. LLM사용이 어려울 때 사용하는 방안

Sem Score

의미론적 유사성을 비교하기 위해 임베딩 모델을 사용. (단순하게 모델이 생성한 답변과 GT를 임베딩하여 cosine similarity를 비교)
아직까지는 영어 데이터에서 높은 성능을 보이며, 특정 도메인 데이터에 사용하기 힘들다. 한국어 임베딩 모델이 없다면 사용하기 어려움.

LLM-based metrics

LLM judge라고도 부르며, 성능이 뛰어난 LLM모델을 이용하기 때문에 비용이 발생하고, 도메인 데이터에 직접 프롬프트를 작성하여 사용 가능.
한국어를 지원하는 LLM에게 사용하여 한국어 적용이 가능
ex) g-eval

 

Q. 어떤 지표를 선호하는가?
A. 영어 문서면 sem score을 추천, 한국어 문서는 sem socre보다는 나머지(딱 떠오르는 embedding model이 없어서).

 

Q. LLM judge의 신뢰성?
A. gpt4 정도의 모델을 사용한 g-eval 메트릭은 실제 사람이 매긴 점수와 거의 유사하다고 생각함.

AutoRAG Module

• 25.03.18 기준 지원

https://github.com/Marker-Inc-Korea/AutoRAG

Query Expansion

Pass, Query Decompose, HyDE, Multi Query Expansion

Retrieval

BM25, VectorDB (Chroma, Milvus), Hybrid RRF, Hybrid CC (mm, tnm, z, dbsf)

Passage Augmenter

Pass, Prev Next Augmenter

Passage Reranker

Pass, Jina, Cohere, VoyageAI, MixedBread AI, UPR, Tart, MonoT5, Sentence Transformer, Flag Embedding, Ko-Reranker, OpenVINO, Flag Embedding LLM, Flashrank, RankGPT

Passage Filter

Pass, Threshold cutoff, Percentile cutoff, Recency, Similarity threshold cutoff, Similarity percentile cutoff

Passage Compressor

Pass, Tree Summarize, Refine, LongLLM Lingua

Prompt Maker

f-string, Long Context Reorder, Window Replacement

Generator

LlamaIndex LLM, OpenAI, OpenAI like, Ollama, AWS Bedrock, HuggingFace llm, Anything in Llama Index LLM, vllm, OpenAI LLM

그러나 현재까지는 grid-search처럼 모든 조합을 진행하는 것이 아닌, 한 단계씩 최적을 찾고 그 이전값이 최적이라는 조건부확률하에 다음 것을 진행함. -> 각 단계별로 지표가 나옴.