RAG from Naive to Modular

Naive RAG

 

1 사전 - 서비스 론칭 전 

1.1 indexing 참고할 문서를 모아주는 역할. pdf, excel, json, word 등등 열어서 모아줌

1.2 chunking 텍스트 긁어모은걸 일정 단위로 쪼개주는 과정 

1.3 embedding 벡터로 표현 (유사도 계산 목적) 

1.4 vectorStore 저장

 

2 실행 - 실제 유저들이 사용하는 실시간 단계 

2.1 Retrieve 제일 중요

2.2 LLM 답변 생성 예쁘게 

 

한계점

포함되는 노이즈가 hallucination 가능성을 높임

 

Advanced RAG

naive RAG의 성능을 높이는 방법을 고민함.

앞의 모든 RAG 단계를 최적화.

 

방법론 5가지

 

1 pre-retrieval 단계

1.1 질문을 그냥 넣지 않고 질문을 예쁘게 만들어서 넣어보기

넓은 범위의 질문 (동화 줄거리 요약 등) 이면 summary를 indexing 해서 넣어주고 summary를 반환해준다 

1.2 hierarchical structure 복합질문 - 한번의 검색으로 해결되지 않는 질문. 

질문을 계층구조로 구성한 후 여러 계층으로 검색 수행하고 합쳐서 답변하는 방식. 

1.3 hybrid indexing 

벡터DB만 쓰지 않고 벡터DB, RDB 판단하여 모두 검색

1.4 chunking strategy

1.4.1 semantic chunking

문맥상, 의미상 유사도에 따라 스마트하게 자르기. 소타 방식. 가장 좋음.

하지만 계산비용이 높음. 대규모 문서작업에는 쓰기 어려움. 

1.4.2 small-to-big

청크 앞뒤로 문맥이 필요할때, (우리회사 이번분기 매출이 100억이다 <- 이번 분기가 언제를 뜻하는지?)

1.4.3 contextual tokens (anthropic사 에서 발표함)

관련 청크에 질문과 비슷한 텍스트가 포함이 되었지만 정확한지 불분명할 경우 를 해결하기 위한 방법 

이 문장의 모호한 부분을 먼저 찾는다. 이 회사, 이번 분기 등. 

보강하기위해 더 넓은 콘텍스트 넣고 보충설명해주는 청크를 새롭게 만든다. 

1.5 Query Rewrite, Expansion, Transformation

쿼리에 키워드를 더 넣어주는 등 

 

2 retrieval 

2.1 hybrid search

two stage retrieval : re rank를 뒤에 추가한 버전

rerank는 계산 시간이 오래 걸림. 그래서 한번 추려내서 주는거다. 

 

3 post-retrieval

reranker = query-document 쌍의 관련성을 평가함.

context reorder = 유사도 검색을 하면 1등부터 10등까지 순차적으로 넣어주게 되는데, llm이 인식할때 1~3번 그리고 맨 뒤에 들어온 문서의 중요도를 높게본다. 그래서 4번째 중요한 문서는 맨 마지막에 넣어줘야함. 

compressor = 노이스 제거 위해서 압축을 하거나 필터링함. 

 

4 generation 

5 indexing 

 

나이브와 어드밴스 모두 리니어 구조의 한계가 있음

단 한번의 기회로 잘 해야 함 

피드백 받고 수정하는 단계가 없음

 

다음의 것들은 순환 구조가 있음

LangGraph, Modular RAG

랭그래프 프레임워크는

로우 레벨 모듈러 래그 중 가장 유명한 프레임워크임. 

 

모듈러 래그는 유지보수가 용이함

인덱싱, 프리 리트리벌, 리트리벌, 등등 각각의 단계마다 모듈화 되어 있어서 레고처럼 빼고 끼우기 좋음. 그래서 응답시간, 성능 등을 고려하여 병렬로 테스트 해보고 선택하기 좋음.

 

만약 질문 여러개가 들어왔는데 전부 다른 맥락에서 물어본 거라면? 

조건부 분기 처리 conditional edge 로직 도입 해서 처리하기도 좋음

 

특수 기능 

human-in-the-loop 챗봇이 판단하여 인간 전문가에게 넘기는 기능

응대 히스토리를 전달해서 인간이 답변 하게끔

 

LangChain 에코 시스템

통합 추적 모니터링 LangSmith

 

랭그래프 State 관리

 

결과물을 상태값이라는 택배상자에 담아서 다음 단계에 전달하면, 이전 단계에서의 작업 처리 방법은 몰라도 결과물은 알 수 있게함. 

각 노드에서 새롭게 업데이트 하는 값은 기존 key 값을 덮어쓰는 방식으로 간다. 다른 key의 기존 값을 지우지도 않는다. 누가 지우지 않는 한 유지된다. 

 

답변에 대한 품질평가 했는데 스코어가 bad여도 리니어 모델에서는 고객에게 가야함. 모듈러에서는 질문을 재작성하여 검색 대상 문서도 바꾸고 답변도 바꿔서 품질 평가를 다시 good이 나올때까지 할수있음. 또는 질문은 그대로 두고 GPT 말고 다른 엔진 등으로 답변만 다시 시켜볼수도 있음. 

 

랭그래프 구현

 

입력과 출력이 동일해야함. 그래야 어디든지 조립이 가능함

edge로 연결을 정의할 수 있음