저도 지금 같은 고민이에요 ㅋㅋ chunk overlap도 함께 조정해야 하더라고요
파인튜닝
RAG 구현할 때 chunk size 어떻게 정하시나요?
요즘 RAG 시스템 만들고 있는데 chunk size 설정에서 계속 헷갈려요. 보통 256부터 1024까지 다양하게 쓰더라고요.
일단 작은 size(256)로 하면 의미 단위로 쪼개지긴 하는데 token 낭비가 심할 것 같고, 큰 size(1024)로 하면 컨텍스트 윈도우는 효율적이지만 관련 없는 정보까지 섞일 가능성이 높아 보여요. 지금 LLM은 Claude Opus 쓰고 있습니다.
혹시 실무에서는 어떤 기준으로 chunk size를 정하세요? 도메인별로 다르게 적용하시는 건가요?
일단 작은 size(256)로 하면 의미 단위로 쪼개지긴 하는데 token 낭비가 심할 것 같고, 큰 size(1024)로 하면 컨텍스트 윈도우는 효율적이지만 관련 없는 정보까지 섞일 가능성이 높아 보여요. 지금 LLM은 Claude Opus 쓰고 있습니다.
혹시 실무에서는 어떤 기준으로 chunk size를 정하세요? 도메인별로 다르게 적용하시는 건가요?
추천 13 비추천 0
- 이전글LLM 파인튜닝 vs 프롬프트 엔지니어링, 어디까지 가봤나요?26.06.21
- 다음글LLM 파인튜닝할 때 LoRA vs full fine-tuning 뭐가 나을까요?26.06.20
댓글
3
댓글목록
저도 그 고민 중이에요 ㅠㅠ
저도 비슷한 고민 많이 했는데, 결국 도메인이랑 문서 특성에 따라 달라지더라고요. 기술 문서나 뉴스는 512 정도가 괜찮은데, 소설이나 긴 내러티브는 1024까지 가도 되는 것 같아요.
Claude 쓰신다면 200k 컨텍스트 윈도우가 있으니까 그냥 큰 사이즈로 가도 실제로는 괜찮긴 한데, 검색 품질이 떨어질 수 있다는 게 문제네요. 저는 일단 512로 해놓고 나중에 retrieval 품질 평가해서 조정하는 방식 쓰고 있습니다.
Overlap도 중요한데 10~20% 정도 설정하면 경계 부분에서 정보 손실 줄어드는 거 확인했어요.
Claude 쓰신다면 200k 컨텍스트 윈도우가 있으니까 그냥 큰 사이즈로 가도 실제로는 괜찮긴 한데, 검색 품질이 떨어질 수 있다는 게 문제네요. 저는 일단 512로 해놓고 나중에 retrieval 품질 평가해서 조정하는 방식 쓰고 있습니다.
Overlap도 중요한데 10~20% 정도 설정하면 경계 부분에서 정보 손실 줄어드는 거 확인했어요.
댓글을 작성하려면 로그인이 필요합니다.