RAG 이해하기: Embedding부터 평가 지표까지

RAG란?

 

RAG(Retrieval-Augmented Generation)의 약자로, 대규모 언어 모델(LLM)이 답변을 생성할 때 외부의 신뢰할 수 있는 지식 소스에서 관련 정보를 검색하고 활용하여 답변의 정확성과 최신성을 높이는 기술이다.

 

위 그림은 AWS에서 제공하는 구성도이다. LLM에게 질문을 할때 답변을 바로 생성하지 않고, Knowledge Sources를 갔다오게끔하는 방식으로 LLM이 어떤 분야에 특화되게끔 만드는데 용이하다.

 

구성은 간단해보이지만, 몇 가지 기술적인 부분들이 접목된다.

 

1. 데이터를 어떻게 표현할까?

2. 데이터를 어떻게 저장할까?

3. 어떻게 평가할 것인가?

 

요즘 이 과정들을 공부하고 있으니 하나씩 알아보자

 

1. Embedding Model

세상에는 수많은 언어들이 있고, 각 언어의 단어 표현 방식도 제각각이다. 이런 데이터를 단순한 텍스트 형태로 저장하면, ‘의미적으로 비슷한 문장’을 찾는 게 사실상 불가능하다. 예를 들어 “고양이가 귀엽다”와 “냥이가 사랑스럽다”는 의미가 비슷하지만, 문자열 비교만으로는 이 둘이 관련 있다고 판단할 수 없다.

이 문제를 해결하기 위해 Embedding(임베딩) 이 등장했다. 임베딩은 텍스트(문장, 단어, 문서 등)를 고차원 벡터 형태로 변환하는 과정이다. 이렇게 하면 문장 간의 의미적 유사도를 수치적으로 비교할 수 있게 된다.

 

데이터는 임베딩 모델이 뱉는 N차원의 벡터로 표현된다.

https://aws.amazon.com/ko/what-is/embeddings-in-machine-learning/

 

모델들은 입력된 문장을 1,536차원 같은 고정 길이 벡터로 변환한다. 고정 길이의 벡터로 표현된 문장들은 아래와 같은 차원에 놓인다 생각하면 편하다.

 

https://aws.amazon.com/ko/what-is/embeddings-in-machine-learning/

그리고 L2 거리(cosine similarity)와 같은 검색 알고리즘을 이용해 유사도를 계산한다. 이 벡터들을 그대로 파일로 저장할 수도 있지만, 실제로는 벡터 데이터베이스(Vector DB) 라는 특수한 저장소를 이용한다.

 

2. Vector Database

다음은 어떻게 저장할까가 고민이 된다. 몇 년 전만 해도 검색을 위해 elastic search 말곤 선택권이 없었지만 요즘은 데이터 규모, 저장하고자 하는 데이터, 검색 방식 등에 따라 선택권이 늘어났다.

 

https://medium.com/@rfajri912/introduction-to-vector-databases-c0a4a855765d

 

이전까지는 문서의 텍스트를 역색인(inverted index) 구조로 저장해 키워드 기반으로 검색했지만, RAG에서는 단어의 의미적 유사성이 중요하기 때문에 단순 텍스트 매칭으로는 부족하다. 이때 사용되는 것이 바로 Vector Database다.

벡터 데이터베이스는 각 문서(혹은 문단)를 임베딩 벡터로 변환해 저장하고, 질문이 들어왔을 때 그 질문을 같은 임베딩 모델로 벡터화하여 벡터 간 유사도 거리(Cosine similarity, Dot product 등) 로 관련 문서를 빠르게 찾아준다.

 

https://www.brilworks.com/blog/what-is-vector-database-types-uses/

 

결국 이 단계의 핵심은 “어떤 데이터를, 어떤 형태로, 얼마나 빠르게 검색할 수 있느냐” 이다. 데이터 양이 많아질수록 인덱싱 전략과 스토리지 구조의 선택이 성능에 직접적인 영향을 주기 때문에, 적절한 벡터 데이터베이스를 고르는 것도 RAG 시스템 성능에 큰 영향을 미친다.

 

왜 RDB는 사용하지 못할까?를 생각해보면, RDB는 기본적으로 정확히 일치하거나 범위로 비교 가능한 값들을 빠르게 조회하기 위해 설계된 구조기 때문에 가장 가까운 벡터(즉, 의미적으로 가장 유사한 문서)를 찾아야 하는 RDB 방식으로는 아쉬운게 사실이다.

 

나는 높은 확률로 Elasticsearch를 사용할 거 같다. 그러나 속도나 환경에 따라서 Qdrant나 Weviate를 사용할 수도 있다.

 

3. 평가 지표들

내가 처음 RAG를 구축할 때만해도, 평가지표를 뭐로 해야할까 고민을 많이 했었다. 그러나 조금만 생각해보면 RAG는 “가장 관련 있는 문서(혹은 문장)”을 찾아내는 추천 시스템과 유사하다. 그래서 RAG의 Retrieval 성능을 평가할 때도 추천 시스템에서 자주 사용하는 지표들을 그대로 가져다 쓴다.

Recall@N
가장 기본적인 지표다. 모델이 검색한 상위 N개의 문서 중에서 정답(ground truth) 이 포함되어 있는지를 평가한다.
즉, “정답이 검색 결과 상위 N개 안에 들어갔는가?”를 측정하는 방식이다.

 

Recall은 ‘놓치지 않고 찾는 능력’을 측정하므로, 검색 단계의 품질을 판단하는 가장 중요한 지표다.

 

MRR (Mean Reciprocal Rank)

Recall은 단순히 정답이 포함되었는지만 보지만, MRR은 정답이 얼마나 상위에 위치했는가까지 고려한다.
정답이 검색 결과의 몇 번째에 등장했는지를 역수로 계산하여 평균을 낸다.

 

수식은 어려워 보이지만 각 등수에 가중치를 먹여서 계산하는 방식이다. 예를 들면, 3개의 질문에 대한 정답 순위가 각각 1위, 2위, 5위였다면 MRR = (1+1/2+1/5)/3 = 0.53 이다.

 

Precision@N 
Recall이 “얼마나 놓치지 않았나”를 본다면, Precision은 “찾은 것 중 얼마나 정확했나”를 본다.
다만 RAG에서는 ‘정답이 여러 개일 수 있다’는 점에서 Precision은 상대적으로 덜 쓰이지만, Retrieval 모델을 튜닝할 때는 여전히 참고된다.

 

이외에도 다양한 지표들이 있지만, 다들 비슷비슷하기도 하고 눈에 띄는 것도 없어서 Recall@N과 MRR을 사용해서 측정했다.

 

마치며

최근 이런 저런일을 겪고 다시 AI 업무를 다시 보고 있다.

 

내가 대학원에 있을 때가 약 7~8년 전이니 그때에 비해 엄청나게 많은 것들이 변했고

 

2년전 쯤에 빠르게 만들었던 AI 어플리케이션에 사용했던 것들이 편의성과 사용성이 눈에 띄게 발전해있었다.

 

그때는 직접 모델을 돌리는 것조차 어려웠는데, 이제는 RAG 파이프라인, 벡터 DB, 임베딩 모델까지 쉽게 쓸 수 있게되었다.

비교하고 실험하는 데만도 꽤 시간을 썼지만, 그만큼 AI 기술의 발전 속도가 체감된다. 

아직도 배워야 할 게 많지만... 새로운 자극이 필요했는데 괜찮은 방향인 것 같다.