티스토리 뷰

1. 기존의 GPT의 한계

1) 할루시네이션 - 잘못된 정보를 자신감 있게 제시

2) 최신 정보 반영이 안됨 - 학습 데이터의 컷오프

3) 도메인특화 - 고유 정보는 없음

4) 지식의 불분명한 출처

 

2. RAG

- 기존의 LLM 답변 생성하는 과정에 검색을 추가하여 답변에 참고할만한 정보를 제공 (문맥 제공)

 

1) Naive RAG: 검색-실행

 

[사전단계]

-  Indexing: PDF, Word, Markdown 등에서 텍스트 데이터를 추출

- Chunking: 작은 단위로 분할

- Embedding: vector로 인코딩

- database: 임베딩된 vector를 저장

 

[실행단계]

- Retrieve: database에서 질문에 답변하기 위한 정보 검색

- Generation: 검색된 정보를 문맥(Context)에 추가하여 답변 생성

 

[한계]

1) 쿼리에 대한 얕은 이해

- 쿼리와 문서 chunk 사이에 의미론적 유사성이 항상 일치하는 것은 아님

- 검색을 위해 유사도 계산에만 의존하는 것은 쿼리와 문서 간의 관계에 대한 심층적인 탐색이 부족

- 문서가 영어로 되어있는데, 질문을 한글로하면 유사도가 상대적으로 낮게 나옴

 

2) 검색 중복 및 노이즈

- 검색된 모든 chunk를 llm에 직접 공급하는 것이 항상 유익한 것은 아님

- 중복되고 노이즈가 많은 정보는 LLM가 핵심 정보를 식별하는데 방해가 되어 잘못된 응답(환각)을 생성할 수 있음

 

=> 검색을 잘하려면 임베딩 잘해야되고, db도 잘되야함

=> 이건 왜 안될까? 그럼 어떻게 해결할 수 있을까? 성능 개선에 초점을 맞춤: Advanced RAG

 

2) Advanced RAG

[사전 단계]

- Indexing : metadata에 연도, 출처(파일명, URL) 등을 추가 → self-query Retreiver: 쿼리문으로 데이터 필터링에 활용

- 넓은 범위의 질문은 요약한 내용을 db에 넣고, 세부 사항에 대한 질문은 잘게 쪼개진 chunck를 다른 db에 저장 후 라우팅으로 질문에 따라 각자 다른 db에서 찾게 함: 쉐어ID를 물려서 요약과 세부사항을 같이 전달해 정보 정확도를 높임

- Hierarchial Structure: 계층적 구조로 검색 범위를 좁히고 대신 검색 depth를 늘림: 답변을 얻기 위해 여러 단계의 추론이나 정보 조합이 필요한 복잡한 질문 유형

- Hybrid Indexing: RDB + VectorDB 

- Semantic Chunking: 의미상 유사한 단락을 기준으로 chunking, 하지만 클러스터링하고 계산해야되는게 많아서 오래 걸림

- Small to Big : 자식-부모 Document구조: 해당 단략의 맥락을 함께 주기 위해서

- Sentence Window: 문단 앞뒤에 2~3문장 같이 저장

 

[검색 전]

- Query Rewrite: 원래 쿼리 의미를 유지하면서 더 명확하고 정보가 풍부한 형태로 쿼리 재작성

예: 서울 맛집 추천 → 서울에서 인기 있는 맛집 추천

- Query Expansion: 관련 용어나 동의어를 추가하여 검색 범위를 확장

예: 서울 맛집 추천 → 서울 맛집 추천 레스토랑 음식점 맛있는 곳 유명한

- Query Transformation: 쿼리의 구조나 형식을 변경

예: 일반 질문을 SQL 쿼리문으로 변환

 

[검색]

- Hybrid Search: 우리나라는 키워드 검색에 익숙하기 때문에 키워드 검색에 가중치를 줄 수도 있음

* 키워드 검색: 정확한 단어 매칭 기반, 시멘틱 검색: 의미와 문맥을 이해해 관련 정보 검색

- Hypothetical Question: 청크들을 사용자가 할 것 같은 질문들을 만들어서 매칭시켜놓음, 예상질문과 실제 사용자 질문의 유사도를 비교해서 Document를 찾아 들어감

-  HyDE: 질문에 예상되는 답변과 청크들의 유사도 비교

- Reranker: Query-Document 쌍의 관련성을 평가: 너무 느리니까 처음 Retreival해서 나온 결과 중에서 Rerank함

- Context Reorder: 관련성이 높은 문서는 시작과 끝에 배치해서 문맥을 줌(LLM은 앞 뒤는 잘 읽고 상대적으로 중간 내용은 참조를 잘 못함)

- Compressor: 노이즈를 제거하고 관련있는 정보만 주자

 

[한계]

- 모든 단계를 한번에 다 잘해야함, 이전 단계로 돌아가기 어려움

- 좋은데? 서비스화 해서 돈 벌어볼까? 유지보수, 효율적인 설계를 고려

 

3) Modular RAG

- 재구성이 용이하고 보다 유연한 프름을 만들 수 있는 프레임워크

- 독립적, 병렬적, 분기 구조가 가능해야 함

- 독립적인 모듈 구성: 모듈 교체 및 추가가 자유로움

 

=> LangGraph

1) Node: RAG 안의 세부 기능을 정의

2) Edge: 노드-노드 간의 연결을 정의(1:N, N:1 연결도 지원 - 병렬처리)

3) 조건부엣지: 조건에 따라 분기 처리

4) 상태: 현재의 상태 값을 저장 및 전달

 

※ 참고 자료: https://www.youtube.com/live/aMUopbBrAmA?si=7sRODmC7H10csj6D

반응형
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2025/04   »
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30
글 보관함