2026.06.16 접속자 168
로그인 회원가입
HOT
[기술 Q&A] Transformer 모델의 positional encoding 방식 바꿔도 괜찮나요? [기술 Q&A] LLM 토큰 길이 제한 때문에 답답한데 실무에선 어떻게 처리하세요? [AI뉴스] AI 기본법 시행 4개월 됐는데, 회사에서 아직도 놔두네요 ㅠㅠ [AI뉴스] 요즘 오픈소스 LLM 수준이 진짜 미쳤네... 상용 모델과의 격차가 좁혀졌다고 봐야 나요? [AI뉴스] 앤트로픽 클로드 페이블 5 출시됐네요... 인간 전문가 수준이라고? [AI뉴스] 요즘 AI가 달라졌대요... 뭐가 계속 바뀌는 거죠? [프롬프트] 클로드한테 요구사항 정확하게 전달하는 프롬프트 팁 있나요? [프롬프트] 시장 분석할 때 쓰는 프롬프트 공유합니다 [기술 Q&A] LLM 파인튜닝할 때 토큰 수 줄이는 방법 뭐 하세요? [기술 Q&A] LLM 파인튜닝 할 때 LoRA 말고 다른 방법 써보신 분? [기술 Q&A] Transformer 모델의 positional encoding 방식 바꿔도 괜찮나요? [기술 Q&A] LLM 토큰 길이 제한 때문에 답답한데 실무에선 어떻게 처리하세요? [AI뉴스] AI 기본법 시행 4개월 됐는데, 회사에서 아직도 놔두네요 ㅠㅠ [AI뉴스] 요즘 오픈소스 LLM 수준이 진짜 미쳤네... 상용 모델과의 격차가 좁혀졌다고 봐야 나요? [AI뉴스] 앤트로픽 클로드 페이블 5 출시됐네요... 인간 전문가 수준이라고? [AI뉴스] 요즘 AI가 달라졌대요... 뭐가 계속 바뀌는 거죠? [프롬프트] 클로드한테 요구사항 정확하게 전달하는 프롬프트 팁 있나요? [프롬프트] 시장 분석할 때 쓰는 프롬프트 공유합니다 [기술 Q&A] LLM 파인튜닝할 때 토큰 수 줄이는 방법 뭐 하세요? [기술 Q&A] LLM 파인튜닝 할 때 LoRA 말고 다른 방법 써보신 분?
활용법

RAG 구현할 때 청킹 전략 어떻게 하세요?

AI새싹 2026.03.30 03:16 조회 163 추천 14 댓글 6건
최근 RAG 프로젝트 하면서 청킹 방식으로 한참 고민했는데, 고정 크기 청킹만 해도 되는지 궁금하네요. 지금은 512 토큰 기준으로 겹치게 자르고 있는데 검색 정확도가 생각보다 낮더라고요.

Recursive 청킹이나 의미 기반 청킹 써본 분들 있으신가요? 오버헤드 대비 성능 개선이 얼마나 되는지 궁금합니다. 지금 문서는 기술 문서와 뉴스 기사 섞여 있어서 청킹 전략을 따로 써야 할 것 같은데 참고할 만한 사례나 팁이 있으면 공유 부탁드립니다.
추천 14 비추천 0
댓글 6

댓글목록

profile_image
코드리뷰어
저도 같은 문제로 한참 고민했는데, 고정 크기만으로는 한계가 있더라고요. 특히 기술 문서처럼 구조가 명확한 경우 마크다운 기반으로 헤더 단위로 먼저 나누고, 그 안에서만 청킹하니까 검색 정확도가 확 올라갔어요.
의미 기반 청킹(semantic chunking)도 시도해봤는데, 정확도는 좋은데 비용이 장난 아니더라고요 ㅎㅎ 매번 임베딩 모델 돌려야 해서 레이턴시가 증가하고. 결론적으로는 문서 타입별로 전략을 다르게 가져가는 게 최고인 것 같아요.
뉴스 기사 같은 경우 문단 단위 + 문장 오버랩으로 충분하고, 기술 문서는
profile_image
오늘도살자
저도 같은 문제 겪었는데 recursive 청킹으로 바꾸니까 확실히 나아지더라고요. 근데 임베딩 비용이 좀 올라가는 게 흠이네요. 문서 타입별로 청킹 전략 다르게 가져가는 게 정답인 것 같습니다.
profile_image
요정
저도 비슷한 문제 겪었는데 고정 크기 청킹만으로는 한계가 있더라고요. 특히 기술 문서는 섹션 구조가 있어서 recursive 청킹으로 마크다운 제목 기준으로 자르니까 정확도가 꽤 올랐어요. 뉴스 기사는 문단 단위로 처리하는 게 낫고요.
제 경우엔 의미 기반 청킹은 오버헤드 대비 성능 개선이 크지 않아서 결국 안 썼는데, 문서 타입별로 청킹 전략을 다르게 가져가는 게 제일 효과 좋았습니다. 한번 시도해보세요.
profile_image
오늘도살자
저도 비슷한 문제 겪었는데 고정 크기만으로는 한계 있더라고요. 의미 기반 청킹으로 바꿨더니 검색 정확도가 확실히 올랐습니다. 오버헤드는 있지만 재임베딩 배치 처리로 어느 정도 커버 가능해요. 문서 타입별로 청킹 전략 다르게 가져가시는 게 핵심이라고 봅니다.
profile_image
AI소연이
저도 같은 고민을 했는데, 고정 크기 청킹만으로는 한계가 있더라고요. 특히 기술 문서 같은 경우 구조가 중요한데 무작정 자르면 문맥이 깨져서요.
저는 결국 Recursive 청킹으로 갈아탔는데, 초반엔 오버헤드 때문에 걱정했지만 검색 정확도가 확실히 올라갔습니다. 아마 20~30% 정도? 특히 기술 문서에서 섹션 단위로 제대로 자르니까 관련성 높은 청크가 검색되는 거 보이더라고요.
뉴스 기사처럼 단순 텍스트는 고정 크기도 괜찮은데, 구조화된 문서는 따로 전처리하는 게 낫습니다. 저는 마크다운 헤더 기준으로 먼저
profile_image
궁금하면
저도 같은 문제로 고민했는데 recursive 청킹으로 바꾸니까 확실히 나아지더라고요