[Week3] 도메인 RAG 파이프라인 구축 및 Chunking 방식 비교

[latteeea]

구현 요약

• Week1~2에서 구현한 ReAct agent 구조 위에 실제 Domain RAG 파이프라인을 추가했다.
• 기존 mock 기반 search_notes를 실제 트러블슈팅 마크다운 문서 검색 기반으로 교체했으며, 실제 Notion API를 연동하기에는 추가적인 데이터 전처리 작업이 필요해 실제 노트의 내용을 복사하여 data/ 폴더 내에 마크다운 파일로 별도 저장하였다.
• 또한 recursive chunking과 markdown header chunking 방식을 비교하여, 노션 스타일 troubleshooting 기록에서 어떤 방식이 더 적합한지 테스트했다.

RAG Pipeline

documents
-> loader
-> chunking
-> embedding
-> FAISS (vectorStore)
-> retriever
-> 2-step RAG Q&A

Chunking 방식

1. Recursive Chunking

• chunk_size = 700
• chunk_overlap = 100
• character 기반 분할

2. Markdown Header Chunking

• markdown heading 기준 분할
• 노션 메모 구조 보존 (실제 노트에서 분리하며 적었던 구조 보존)

Chunking 방식 비교

Query	Recursive 결과	Markdown Header 결과	해석
외부 API 변경으로 장애가 발생한 사례	X-Username, pgadmin_killed	spotify_api, X-Username	markdown이 장애 흐름을 더 잘 유지
사용자 인증 정보 불일치 사례	X-Username 중심	X-Username 중심	둘 다 유사하지만 markdown이 원인 흐름 보존
수동 검토와 자동 검증 사례	llm_verify1, multi_agent	llm_verify1 중심	markdown이 의미 단위 유지
안드로이드 빌드 배포 에러 사례	pgadmin_killed, android_build_error	spotify_api, android_build_error	recursive는 노이즈 존재
long polling 서버 다운 사례	long_polling 일부 chunk	long_polling 구조 단위 chunk	markdown이 흐름 이해에 유리

최종 선택

노션 기반 자유 형식 트러블슈팅 메모에서는 세부 token 기반 recursive chunking보다 markdown heading 기반 chunking이 문제 해결 흐름과 구조적 문맥을 더 안정적으로 유지하는 것을 확인했다. (아마 같은 개념이 다른 트러블슈팅 사례의 각 문제로 산재되어 있어서 그런것으로 추측한다)

따라서 최종 retrieval 전략으로 markdown header chunking을 선택했다 !