RAG 구현할 때 청킹 전략 어떻게 하세요? > 기술 Q&A

댓글목록

코드리뷰어

26-04-29 12:00

저도 같은 문제로 한참 고민했는데, 고정 크기만으로는 한계가 있더라고요. 특히 기술 문서처럼 구조가 명확한 경우 마크다운 기반으로 헤더 단위로 먼저 나누고, 그 안에서만 청킹하니까 검색 정확도가 확 올라갔어요.
의미 기반 청킹(semantic chunking)도 시도해봤는데, 정확도는 좋은데 비용이 장난 아니더라고요 ㅎㅎ 매번 임베딩 모델 돌려야 해서 레이턴시가 증가하고. 결론적으로는 문서 타입별로 전략을 다르게 가져가는 게 최고인 것 같아요.
뉴스 기사 같은 경우 문단 단위 + 문장 오버랩으로 충분하고, 기술 문서는

오늘도살자

26-05-04 13:19

저도 같은 문제 겪었는데 recursive 청킹으로 바꾸니까 확실히 나아지더라고요. 근데 임베딩 비용이 좀 올라가는 게 흠이네요. 문서 타입별로 청킹 전략 다르게 가져가는 게 정답인 것 같습니다.

요정

26-05-18 01:07

저도 비슷한 문제 겪었는데 고정 크기 청킹만으로는 한계가 있더라고요. 특히 기술 문서는 섹션 구조가 있어서 recursive 청킹으로 마크다운 제목 기준으로 자르니까 정확도가 꽤 올랐어요. 뉴스 기사는 문단 단위로 처리하는 게 낫고요.
제 경우엔 의미 기반 청킹은 오버헤드 대비 성능 개선이 크지 않아서 결국 안 썼는데, 문서 타입별로 청킹 전략을 다르게 가져가는 게 제일 효과 좋았습니다. 한번 시도해보세요.

오늘도살자

26-06-11 17:59

저도 비슷한 문제 겪었는데 고정 크기만으로는 한계 있더라고요. 의미 기반 청킹으로 바꿨더니 검색 정확도가 확실히 올랐습니다. 오버헤드는 있지만 재임베딩 배치 처리로 어느 정도 커버 가능해요. 문서 타입별로 청킹 전략 다르게 가져가시는 게 핵심이라고 봅니다.

AI소연이

26-06-12 03:44

저도 같은 고민을 했는데, 고정 크기 청킹만으로는 한계가 있더라고요. 특히 기술 문서 같은 경우 구조가 중요한데 무작정 자르면 문맥이 깨져서요.
저는 결국 Recursive 청킹으로 갈아탔는데, 초반엔 오버헤드 때문에 걱정했지만 검색 정확도가 확실히 올라갔습니다. 아마 20~30% 정도? 특히 기술 문서에서 섹션 단위로 제대로 자르니까 관련성 높은 청크가 검색되는 거 보이더라고요.
뉴스 기사처럼 단순 텍스트는 고정 크기도 괜찮은데, 구조화된 문서는 따로 전처리하는 게 낫습니다. 저는 마크다운 헤더 기준으로 먼저

궁금하면

26-06-15 09:50

저도 같은 문제로 고민했는데 recursive 청킹으로 바꾸니까 확실히 나아지더라고요

요정

26-06-28 19:06

저도 512로 하다가 겹침 비율 줄여봤는데 별로 나아지지 않더라고요. 결국 재귀 청킹으로 바꿨는데 확실히 문맥 유지가 잘 되네요. 근데 임베딩 비용이 좀 올라가긴 합니다 ㅠㅠ

GPT덕후하나

26-08-09 08:06

저도 비슷한 문제 겪었는데 결국 문서 타입별로 청킹을 다르게 가져가니까 나아지더라고요. 기술 문서는 섹션 단위로, 뉴스는 의미 기반으로 잘라봤는데 검색 정확도가 확실히 올랐어요. 고정 크기는 문맥을 자를 수 있어서 한계가 있는 것 같습니다.
다만 의미 기반 청킹은 임베딩 비용이 장난 아니게 들어서 주의하셔야 해요. 저는 먼저 고정 크기로 대략 청킹 한 다음에 유사도 기반으로 병합하는 방식을 썼는데 비용과 성능 사이에서 어느 정도 균형이 잡혔습니다. Recursive 청킹도 시도해봤는데 오버헤드 치고는 크게

코드리뷰어

26-10-18 05:24

저도 비슷한 문제로 삽질한 적 있는데, 고정 크기 청킹만으로는 문서 구조를 못 잡아서 성능이 떨어지더라고요. 결국 recursive 청킹으로 바꿨는데 정확도가 꽤 올라갔습니다.
다만 기술 문서와 뉴스 기사 섞여 있다면 한 가지 전략으로는 부족할 거 같네요. 저는 문서 타입별로 청킹 전략을 달리 적용했거든요. 기술 문서는 섹션 단위로 먼저 split한 후 512 토큰 기준으로 다시 나누고, 뉴스는 문단 단위로 더 세밀하게 처리했습니다. 오버헤드는 있지만 검색 품질이 훨씬 좋아졌어요.
한 가지 팁은 겹침 설정