개발관련/AI 이야기

PDF 문서 기반 Q&A 시스템 구축: LlamaIndex, ChromaDB, Ollama 활용 3부

후니의 개발이야기 2025. 5. 27. 13:41
728x90
반응형

앞선 2부에 보시면 답변이 나오는데 제 생각에는 마음에 들지 않았어요. 
그래서 조금더 고민을 해 보았습니다. 
어떻게 하면 성능이 더 올라가게 만들수 있을까 하구요. 
조금더 조정된 방법입니다. 

RAG시스템에 Chunking 을 적용

RAG(Retrieval-Augmented Generation) 시스템에서는 문서를 임베딩 벡터로 변환한 후, 이를 ChromaDB 같은 벡터 데이터베이스에 저장하여 검색에 활용합니다.
그런데 문서를 통째로, 혹은 너무 큰 단위로 인덱싱하면 다음과 같은 문제가 발생할 수 있습니다

1. 정보의 세분화 부족 
    큰 텍스트 블록은 개별 정보가 희석되기 때문에, 사용자의 질문과 관련된 내용을 정확히 매칭하기 어려워집니다.

2. LLM 문맥처리의 한계
    예를 들어 Mistral 같은 LLM은 약 8,000토큰의 제한이 있습니다.
    너무 큰 chunk는 이 한도를 초과할 수 있어, 일부 내용이 잘리거나 제대로 처리되지 않을 수 있습니다.

3. 불필요한 문맥 포함
    너무 많은 내용을 한 번에 검색하면 질문과 상관없는 정보도 함께 들어와 오히려 응답 품질을 떨어뜨릴 수 있습니다.

4. 작고 명확하게 쪼갠 chunk는 특정 질문 의도에 더 잘 맞기 때문에, 벡터 유사도 기반 검색 효율도 높아집니다.

방법

 TextSplitter 설정을 통해서 chunking  적용을 해보시면 됩니다.

#추가된 부분 아래부분은 차후 튜닝필요한 부분 
    print("Splitting documents into chunks")
    try:
        splititer = SentenceSplitter(
            chunk_size=512,  #Max tokens per chunk 
            chunk_overlap=50 #Overlap between chunks
        )
        nodes = splititer.get_nodes_from_documents(documents)
        print(f"create : {len(nodes)}")
    except Exception as e:
        print(f"Failed to split document: {e}")
        return

위와 같은 부분을 소스에 더 추가하고 2부에서 질의한 것을 비교해보면 훨씬 더 잘 나온 것을 알 수 있더라구요. 

한단계 더 나아진것 같죠? 
역시 모르는것에 대해서 알아가는 과정은 힘들지만 그래도 한단계씩 업그레이드 되는 느낌이네요 ㅎㅎ 

즐거운 코딩되세요. 

728x90