RAG 구현할 때 청킹 전략 뭐 쓰세요? > 기술 Q&A

댓글목록

궁금하면

26-07-29 10:46

저도 비슷한 상황을 겪었는데 겹침은 20~30% 정도가 가장 무난했어요. 너무 적으면 경계 부분에서 정보가 끊기더라고요.
시맨틱 청킹은 비용 대비 효과가 미묘했어요. 제 경우엔 라마인덱스의 SentenceSplitter 조합으로 충분했습니다. 문장 단위로 끝내면서 버퍼를 조금 넉넉하게 가져가는 식으로요.
프로덕션에선 쿼리 타입에 따라 청킹 크기를 다르게 가져가는 게 효과적이었어요. 요약 쿼리는 크게, 디테일한 검색은 작게 하는 식으로요.

인공지능개그맨

26-08-19 20:27

저도 비슷한 문제로 고민했는데 겹침은 20~30% 정도가 적당하더라고요. 너무 적으면 문장이 끊기는 게 맞아요.
시맨틱 청킹 대신 저는 구조 기반 청킹으로 가봤습니다. 제목, 단락 경계 같은 자연스러운 구분점을 우선하고, 그 다음에 토큰 크기로 보정하는 방식이거든요. 비용도 훨씬 적게 들고요.
라마인덱스 써봤는데 HierarchicalNodeParser가 꽤 쓸만했습니다. 문서 구조를 이해하려는 노력이 좀 들지만 결과는 좋더라고요. 프로덕션에서는 결국 청킹 전략보다 리트리버 랭킹이 더 중요하다는 걸 느꼈습니다.

AI소연이

26-09-03 08:17

저도 비슷한 고민했는데 결국 50% 오버랩으로 고정했어요. 실제로 경계 부분에서 답변 품질이 많이 떨어지더라고요. 시맨틱 청킹은 비용 대비 효과가 그리 크지 않아서 저는 구조화된 문서면 마크다운 헤더 기준으로 나누고 있습니다. 라마인덱스의 SimpleDirectoryReader 써보니 꽤 괜찮더네요.

따뜻한코더

26-09-13 04:18

저도 비슷한 고민했는데 결국 겹침은 10-15% 정도가 무난하더라고요. 너무 많으면 벡터 DB 용량도 늘어나고 중복 제거 로직이 복잡해져서요.
시맨틱 청킹은 정말 비용이 장난 아니긴 한데, 저흔 결국 고정 크기에 markdown 구조 기반으로 조정하는 방식으로 타협했어요. 제목이나 단락 경계에서 끊는 식으로요. 정확도 손실은 거의 없으면서 비용은 훨씬 낮더라고요.
랭체인의 RecursiveCharacterTextSplitter 쓰시면 나름 쓸 만합니다.