저도 의미론적 청킹 시도했는데 정말 결과가 좋더라고요. 다만 말씀하신 대로 전처리 시간이 문제네요. 배치 사이즈 줄이고 병렬 처리하니까 좀 개선됐어요. 그리고 한국어 같은 경우 형태소 분석기 거쳐서 청킹하면 품질이 훨씬 나아집니다.
프롬프트
RAG 구현할 때 청킹 전략 어떻게 하세요?
요즘 LLM 프로젝트에서 RAG를 붙이려고 하는데 문서 청킹 부분에서 자꾸 막혀요. 단순하게 고정 크기로 쪼개다 보니까 문맥이 끊기는 경우가 많더라고요. 특히 테이블이나 코드 블록이 섞여 있으면 정말 답답합니다.
지금 시도해본 방식들을 정리해보면, 먼저 토큰 단위로 청킹하는 게 가장 무난하다는 생각이 드네요. 고정 크기 청크(보통 512~1024 토큰)에 오버랩을 주는 방식인데, 이렇게 하면 청크 경계에서 문맥 손실을 어느 정도 줄일 수 있습니다. 다만 임베딩 계산량이 늘어나는 게 단점이긴 합니다.
요새 떠는 의미론적 청킹도 실험 중이거든요. 문장 단위로 끊고 임베딩 유사도 기반으로 묶는 방식인데, 구현은 좀 복잡하지만 결과가 확실히 낫더라고요. 다만 전처리 시간이 생각보다 오래 걸려서 대용량 데이터셋에서는 고민이 됩니다. 누군가 효율적으로 처리하는 팁이 있으면 듣고 싶네요.
그리고 한국어 자료 다루실 분들은 청킹 전에 품질 검사가 정말 중요합니다. OCR 오류라든지 형식 깨진 부분을 먼저 정리해야 나중에 RAG 품질이 안 떨어져요. 저는 최근에 정규식으로 간단하게라도 거르는 스텝을 앞에 붙였는데 효과가 꽤 있었습니다.
혹시 프로덕션 환경에서 동적으로 청킹 크기를 조정하는 분 계신가요? 문서 타입에 따라 최적의 청크 크기가 다를 것 같은데 어떻게 대응하고 계신지 궁금합니다.
지금 시도해본 방식들을 정리해보면, 먼저 토큰 단위로 청킹하는 게 가장 무난하다는 생각이 드네요. 고정 크기 청크(보통 512~1024 토큰)에 오버랩을 주는 방식인데, 이렇게 하면 청크 경계에서 문맥 손실을 어느 정도 줄일 수 있습니다. 다만 임베딩 계산량이 늘어나는 게 단점이긴 합니다.
요새 떠는 의미론적 청킹도 실험 중이거든요. 문장 단위로 끊고 임베딩 유사도 기반으로 묶는 방식인데, 구현은 좀 복잡하지만 결과가 확실히 낫더라고요. 다만 전처리 시간이 생각보다 오래 걸려서 대용량 데이터셋에서는 고민이 됩니다. 누군가 효율적으로 처리하는 팁이 있으면 듣고 싶네요.
그리고 한국어 자료 다루실 분들은 청킹 전에 품질 검사가 정말 중요합니다. OCR 오류라든지 형식 깨진 부분을 먼저 정리해야 나중에 RAG 품질이 안 떨어져요. 저는 최근에 정규식으로 간단하게라도 거르는 스텝을 앞에 붙였는데 효과가 꽤 있었습니다.
혹시 프로덕션 환경에서 동적으로 청킹 크기를 조정하는 분 계신가요? 문서 타입에 따라 최적의 청크 크기가 다를 것 같은데 어떻게 대응하고 계신지 궁금합니다.
추천 7 비추천 0
- 이전글LLM 토큰 길이 제한 때문에 고민이신 분 계신가요?26.07.20
- 다음글트랜스포머 모델에서 attention 계산 효율 개선해본 분 있나요?26.07.11