티스토리 뷰
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
'AI > AI 서비스 개발' 카테고리의 다른 글
[AI 서비스 개발] AI 여행플래너 서비스 프로젝트 관련 용어 복기 (0) | 2025.03.18 |
---|---|
[AI 서비스 개발] 크롤링 방지 기법, 크롤링 정책 (0) | 2025.03.17 |
[AI 서비스 개발] LLM의 Reasoning, Deepseek R1, 파인튜닝과 강화학습 (0) | 2025.03.11 |
[AI 서비스 개발] RAG 파이프라인 (0) | 2025.03.06 |
[AI 서비스 개발] 확장성을 고려한 K8S 기반 소프트웨어 아키텍처 설계 (0) | 2025.03.03 |
- Total
- Today
- Yesterday
- IH
- 30분
- 아침
- Python
- 운동
- 오블완
- 오픽
- C언어
- 뉴스
- 경제
- 갓생
- 아침운동
- llm
- 영어회화
- 줄넘기
- 다이어트
- Ai
- opic
- 기초
- ChatGPT
- 스크랩
- 미라클모닝
- SQL
- 빅데이터 분석기사
- 프로그래머스
- 루틴
- 습관
- 티스토리챌린지
- 실기
- 고득점 Kit
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |