저도 비슷한 경험했는데 recursive splitter가 정답인 것 같아요. 속도가 느린 건 맞지만 결국 청킹 품질이 임베딩 전체 퀄리티를 좌우하니까요. 프로덕션에선 청크 overlap을 30~50% 정도 줘서 의미 경계 손실을 보완하고 있어요. 테이블 같은 경우엔 따로 프리프로세싱으로 마크다운 포맷으로 변환해서 넘기는 게 도움이 됐습니다.
오류해결
최근에 RAG 구현할 때 청킹 전략 뭐 쓰세요?
개인 프로젝트에서 RAG 시스템 만들고 있는데 문서 청킹 방식 때문에 고민이 생겼어요. 처음엔 그냥 고정 크기(512 토큰)로 잘라냈는데 의미 단위가 깨지는 경우가 많더라고요. 특히 테이블이나 리스트 형식 데이터는 거의 망가져요.
요즘엔 recursive character splitter 써보고 있는데 확실히 나아지는 느낌은 있어요. 다만 처리 속도가 조금 느려지는 게 단점이네요. 혹시 프로덕션에서는 어떤 방식 써보신 분 계신가요? 벡터 임베딩 품질 개선도 중요하지만 청킹 자체가 정말 중요하다는 걸 느껴요.
요즘엔 recursive character splitter 써보고 있는데 확실히 나아지는 느낌은 있어요. 다만 처리 속도가 조금 느려지는 게 단점이네요. 혹시 프로덕션에서는 어떤 방식 써보신 분 계신가요? 벡터 임베딩 품질 개선도 중요하지만 청킹 자체가 정말 중요하다는 걸 느껴요.
추천 13 비추천 0
- 이전글요즘 로컬 LLM 뭐 쓰시나요? 프라이빗한 작업용으로26.04.01
- 다음글요즘 Claude 3.5 Sonnet 써보셨나요?26.03.31
댓글
8
댓글목록
저도 같은 고민 했거든요. recursive splitter 쓰다가 속도 때문에 결국 semantic chunking으로 갈아탔어요. 문장 단위로 끊은 뒤 임베딩 유사도로 병합하는 방식인데 청크 품질이 훨씬 낫더라고요. langchain의 semantic splitter 한번 시도해보세요. 초기 세팅만 잘하면 후속 처리 속도도 나쁘지 않습니다.
저도 recursive splitter 써보니 품질은 훨씬 낫더라고요 ㅋㅋ
저도 비슷한 경험 했는데 결국 semantic chunking 써보니까 훨씬 낫더라고요. 속도도 생각보다 괜찮고 특히 테이블 같은 구조화된 데이터 처리가 훨씬 깔끔해요.
청킹이 정말 중요하더라고요 ㅋㅋ
저도 비슷한 고민 했는데 결국 semantic chunking으로 가봤어요. 속도는 좀 느리지만 retrieval 정확도가 확실히 달라지더라고요. 특히 복잡한 문서에서요.
저도 처음엔 고정 크기로 했는데 시멘틱 청킹으로 바꿨어요. 문장 끝이나 단락 기준으로 자르니까 의미 단위가 훨씬 낫더라고요. 속도는 recursive splitter보다 빠르고요. 테이블 같은 경우는 별도로 처리하는 게 맞는 것 같습니다.
저도 같은 문제 겪었는데 정말 답답하더라고요 ㅠㅠ
댓글을 작성하려면 로그인이 필요합니다.