RAG 시스템은 단순한 LLM 호출이 아니라, 여러 단계로 이루어져있다.사용자 질문관련 문서 검색문서를 프롬프트에 넣기LLM 답변 생성출처와 함께 반환그래서 RAG 답변이 틀렸을 때 원인도 여러 가지다.검색이 잘못됐을 수 있다.검색은 맞았는데 LLM이 문서를 잘못 읽었을 수 있다.답은 맞았는데 출처가 틀렸을 수 있다.문서 자체가 오래됐을 수 있다.RAG 평가는 이 원인을 분리해서 보는 작업이다.예시로 보기질문이 들어왔다고 하자.질문:해외배송 상품을 환불하면 위약금은 얼마인가요?정답을 만들려면 두 개의 근거가 필요하다.근거 A: 해외배송 상품의 환불 정책근거 B: 환불 정책이 참조하는 위약금 산정 조항RAG 시스템은 이 두 근거를 찾아서 LLM에게 줘야 한다.정상적인 흐름은질문 → 검색 단계에서 A와 B를..
RAG나 임베딩 검색을 만들면 결국 이런 작업을 해야 한다.질문을 벡터로 바꾼다.문서 조각들도 벡터로 저장해둔다.질문 벡터와 가장 가까운 문서 벡터를 찾는다.예를 들어 사용자가 이렇게 묻는다고 하자: "택배가 아직 안 왔을 때 보상 받을 수 있나요?"이 질문은 문서의 정확한 문장과 단어가 다를 수 있는데,문서에는 "배송 지연으로 인한 보상 기준은 다음과 같다." 라고 쓰여있을 수 있다.즉, 키워드는 완전히 같지 않고, 그러나 의미는 가깝다.임베딩 검색은 이런 의미 유사성을 이용하는데, 문제는 문서가 많아졌을 때다.문서 조각 1,000개 → 하나씩 비교 가능문서 조각 100만 개 → 하나씩 비교하면 느림문서 조각 1억 개 → 단순 비교는 거의 불가능그래서 필요한 것이 Vector DB와 ANN 검색이다.V..
RAG의 한계에서 출발RAG는 질문과 벡터가 "직접 비슷한" 문서만 찾는다. 그런데 실제 질문은 종종 여러 단계를 거쳐야 답이 나오는 경우가 있다.e.g) "해외배송 상품을 환불하면 위약금은 얼마인가?먼저 "해외배송 상품의 환불 정책이 무엇인지"를 찾고그다음 "그 환불 정책이 참조하는 위약금 산정 조항"을 찾아야 한다이 두 조각이 임베딩 공간에서 서로 가깝지 않을 수 있다. "위약금 산정 조항"이라는 텍스트는 "해외배송 환불 정책"이라는 텍스트와 단어도 다르고 문맥도 다를 수 있다. 벡터 검색만으로는 이런 "간접적으로 연결된" 정보를 놓치기 쉽다.GraphRAG는 문서 조각들 사이의 명시적인 관계(어떤 조항이 어떤 조항을 참조하는지, 어떤 정책이 어떤 정책을 인용하는지)를 그래프로 미리 저장해두고, 검색..
1.RAG?검색(Retrieval): 질문과 관련된 문서 조각을 데이터베이스에서 먼저 찾아온다증강(Augumented): 찾아온 문서 조각을 LLM 프롬프트에 근거로 추가(증강)한다생성(Generation): LLM이 그 근거를 바탕으로 답변을 생성한다문제 상황LLM은 학습 시점까지의 데이터만 알고 있다. 회사 내부 정책 문서, 최신 이용약관, 특정 서비스의 세부 매뉴얼처럼 모델이 애초에 본 적 없는 정보는 답변에 반영할 수 없다. 예를 들어 쇼핑몰 CS 챗봇이 "이번에 바뀐 해외배송 환불 규정"을 답변에 반영하려면, 그 규정 문서를 어떻게든 모델에게 전달해야 한다. 이걸 해결하는 가장 직관적인 방법은 "필요한 정보를 프롬프트에 직접 넣어주는 것"인데, 문서 전체를 매번 통째로 넣으면 비용이 크고 비효율..
