RAG 대 Jev + RAG 비교 설명

표준 RAG(Retrieval-Augmented Generation) 설정에서는 문서를 청크(chunks)로 분할하고, 임베딩(embeddings)으로 변환한 다음 벡터 DB(vector DB)에 저장합니다.

쿼리가 도착하면 시스템은 이를 임베딩하고 가장 가까운 벡터를 가진 상위 k개의 청크를 검색합니다.

많은 프로덕션 설정에서는 검색 후 리랭커(reranker)를 추가합니다.

리랭커는 쿼리와 각 검색된 구절을 비교하여 순서를 개선하고, 가장 높은 점수를 받은 결과만 유지합니다.

그 구절들은 컨텍스트 창(context window)에 배치되고, LLM이 그 내용으로부터 답변을 생성합니다.

문제는 순위와 답변 가능성(answerability)이 서로 다른 질문이라는 것입니다.

어떤 구절은 다른 후보들보다 더 관련성이 높을 수 있지만, 여전히 약하거나 불완전하거나 단순히 인접한 증거만을 포함할 수 있습니다.

그럼에도 불구하고 LLM은 이를 받고, 실제로는 전혀 뒷받침되지 않은 컨텍스트로부터 그럴듯한 답변을 생성할 수 있습니다.

Jev + RAG는 검색 단계를 그대로 유지하지만, 생성(generation) 전에 발생하는 일을 변경합니다.

이 단계에서 기존의 리랭커를 사용하는 대신, Jev는 다음과 같은 유형화된 질문에 대해 검색된 모든 후보들을 판단할 수 있습니다:

"이 구절이 쿼리에 답변하는 데 도움이 되는가?"

쿼리가 공유 상태(shared state)가 되고, 검색된 구절들이 개별 후보가 됩니다. Jev는 이들을 함께 평가하고 각각에 대한 확률을 반환합니다.

애플리케이션 코드는 그 후 임계값(threshold)을 적용합니다.

↳ 임계값을 초과하는 후보들은 LLM으로 계속 전달됩니다.
↳ 임계값 미만인 후보들은 컨텍스트 창에서 제거됩니다.

동일한 Jev 요청은 남아 있는 증거가 쿼리에 답변하기에 충분한지 여부도 판단할 수 있습니다.

답변 가능성이 임계값보다 낮으면, 애플리케이션은 LLM을 건너뛰고 "문서에 없음"을 반환할 수 있습니다.

Jev는 임베딩 모델, 벡터 데이터베이스 또는 생성 모델을 대체하지 않습니다. 검색이 여전히 한계를 설정하기 때문입니다. Jev는 후보 집합에 들어가지 않은 구절을 복구할 수 없기 때문입니다.

아래 다이어그램은 전체 흐름을 묘사합니다.

• RAG가 광범위한 후보 집합을 검색합니다.
• Jev가 해당 후보들을 재순위화하고 게이팅(gating)합니다.
• LLM이 답변을 생성합니다.

더 깊이 알고 싶으시다면, 저는 또한 오픈 모델을 사용하여 Jev 스타일의 모델을 완전히 로컬에서 구축하는 방법을 보여주는 실습 가이드도 작성했습니다.

아래에서 읽어보세요.