•
이미지, 텍스가 포함된 문서를 어떤식으로 RAG로 처리할 거냐..
•
query + context(이미지를 binary로) LLM에 같이 넘긴다.
•
전처리
◦
문서 해석: 문서내 데이터중에 글,이미지,테이블 식별을 위해 LLM 필요
•
Multimodal PDF 검색 성능을 높이려면?
◦
PDF 문서에 맞는 전처리
◦
검색어에 대해 가능한 정답이 포함될 수 있도록 Vector DB의 인덱스를 잘 구성하기
▪
불필요한 데이터도 가능한 많이 넣고 LLM이 정제하도록…
◦
의도와 상황에 맞는 프롬프트 엔지니어링으로 LLM 모델을 잘 활용하기
•
PDF 데이터 전처리
◦
데이터 전처리로 텍스트, 이미지, 테이블로 PDF 데이터를 분류, 추출
◦
Python 라이브러리를 활용한 PDF 문서 분석
◦
Upstage 문서 분석 성능 괜찮은것 같다.
◦
PDF 문서 전처리 시 고려 사항
▪
기본적인 검색 단위
•
PDF 문서 한 페이지
•
문서 내 개별 이미지 또는 개별 테이블
▪
문서 이미지의 DPI
•
DPI가 낮으면 OCR 성능 영향
•
적정 DPI : 150~250
▪
문서 내 개별 이미지 추출
•
Caption(주변 텍스트) 추출을 위한 전처리 필요
→ 이미지 검색을 위해 텍스트를 메타데이터로 저장
▪
OCR 또는 문서 구조 파악을 위한 임베딩 모델 선택
•
Multimodal Embedding 모델(ex. Amazon Titan Multimodal Embedding)
•
일반 이미지 인식 가능한 LLM 모델(ex. Anthropic Claude3, 3.5)
•
데이터 전처리를 잘하려면?
◦
문서의 형식에 맞는 임베딩 모델 선택
◦
자주 실험하고 변경이 가능하도록 유연한 구현을 하기
◦
다양한 PDF 분석 라이브러리를 실험해 보기
•
Vector DB(OpenSearch) 데이터 입력
◦
자연어 검색을 위해 Vector DB를 쓴다.
▪
키워드 검색 X
◦
Amazon OpenSearch Serverless 내에 Nori 형태소 분석기 기본 포함
◦
임베딩 후 입력 또는 OpenSearch에 입력시 자동 임베딩
◦
임베딩 벡터 차원 최대 1024 사용
◦
데이터 저장 공간의 절반 정도 가량 메모리 여유공간으로 확보
▪
Heap 사이즈
•
더 나은 Index 구성을 하려면?
◦
Hybrid 검색(Lexical + Semantic Search) 고려
◦
검색 정확도를 높이기 위한 형태소 분석기 사용자 사전 구성
◦
다양한 벡터 검색 알고리즘 시도(KNN, HNSW등)
•
Amazon Bedrock를 활용한 PDF 검색
◦
Claude Sonnet 3.5 모델의 Request 허용 범위
▪
단일 이미지 당 5MB 이하
▪
최대 20장의 이미지
◦
Query(사용자 검색어) Rerouting
▪
Vector DB에 저장된 데이터 종류 고려
▪
사용자 검색어의 시나리오 또는 의도에 맞게 검색 대상 Index, Type을 변경
◦
프롬프트 엔지니어링의 중요성
▪
원하는 상황과 기나리오에 맞게 정확한 지시를 담은 프롬프트 필요
•
더 나은 검색을 구현하려면?
◦
Amazon Bedrock Agent로 Agent 패턴 구현
◦
Vector DB의 검색 결과 중 유사도를 기준으로 동적으로 검색 결과 수 조정
◦
Vector DB의 검색 결과 재정렬(Reranking)
▪
요즘 LLM 성능이 좋아져서 Reranking 의미가 없는 것 같다.