Retrieval Augmented Generation (RAG)은 오버로드된 용어입니다. 이 용어는 세상을 약속하지만, RAG 파이프라인을 개발한 후에는 우리 많은 사람들이 왜 예상했던 것만큼 잘 작동하지 않는지 궁금해합니다.
대부분의 도구와 마찬가지로 RAG는 사용하기 쉽지만 숙달하기 어렵습니다. 사실, RAG에는 문서를 벡터 DB에 넣고 위에 LLM을 추가하는 것 이상의 것이 있습니다. 그 방법으로는 작동할 수 있지만 항상 그렇지는 않습니다.
이 eBook은 RAG가 기본 설정대로 작동하지 않을 때 어떻게 해야 하는지 알려주기 위한 것입니다. 이 첫 번째 장에서는 종종 최적이 아닌 RAG 파이프라인에 대한 가장 쉽고 빠르게 구현할 수 있는 해결책에 대해 살펴볼 것입니다. 우리는 '재순위 지정자'에 대해 배우게 될 것입니다.
이 장의 비디오 동반자.
리콜 대 컨텍스트 윈도우
해결책에 들어가기 전에 문제에 대해 이야기해 봅시다. RAG를 사용하여 많은 텍스트 문서를 _의미론적 검색_하고 있습니다. 이 문서들은 수십만 개에서 수십억 개에 이를 수 있습니다.
대규모 검색 시 빠른 검색 시간을 보장하기 위해 일반적으로 벡터 검색을 사용합니다. 즉, 텍스트를 벡터로 변환하여 모두를 벡터 공간에 배치하고 코사인 유사도와 같은 유사성 측정 항목을 사용하여 쿼리 벡터와의 근접성을 비교합니다.
벡터 검색을 위해 벡터가 필요합니다. 이러한 벡터는 일반적으로 768 또는 1536 차원의 '의미'를 압축한 것입니다. 이 정보를 단일 벡터로 압축하기 때문에 일부 정보 손실이 있습니다.
이 정보 손실로 인해 종종 상위 세 개(예를 들어)의 벡터 검색 문서에서 관련 정보를 놓치는 경우가 많습니다. 유감스럽게도, 검색 결과는 상위_k 값 아래의 관련 정보를 반환할 수 있습니다.
하위 위치에 있는 관련 정보가 LLM이 더 나은 응답을 구성하는 데 도움이 될 경우 어떻게 해야 할까요? 가장 쉬운 방법은 반환하는 문서 수를 늘리고(top_k를 증가시킴) 모두 LLM에 전달하는 것입니다.
여기에 측정할 메트릭은 _재현율_입니다. 즉, '관련 문서 중 몇 개를 검색했는가'를 의미합니다. 재현율은 검색된 총 문서 수를 고려하지 않으므로, 우리는 이 메트릭을 조작하여 _모든 것_을 반환함으로써 완벽한 재현율을 얻을 수 있습니다.