의미론적 청킹 비용 정말 크더라고요 ㅠㅠ
활용법
RAG 시스템 구축 중에 청킹 전략 때문에 헷갈려요
요즘 LLM에 자사 데이터를 연결하려고 RAG 시스템을 만들고 있는데, 문서 청킹 부분에서 자꾸 막히네요. 고정 크기로 청킹하니까 문맥이 끊어지는 경우가 많고, 겹치게 하니까 중복된 검색 결과가 너무 많이 나오더라고요.
지금은 의미론적 청킹(semantic chunking)을 시도해보고 있는데, 계산 비용이 생각보다 크다는 게 문제입니다. 우리 팀이 작아서 비용 효율을 신경 써야 하는데 좋은 방법이 있을까요?
혹시 프로덕션 환경에서 청킹 쓰고 계신 분 계신가요? 어떤 방식으로 하고 있는지, 그리고 임베딩 모델은 뭘 쓰시는지 궁금합니다.
지금은 의미론적 청킹(semantic chunking)을 시도해보고 있는데, 계산 비용이 생각보다 크다는 게 문제입니다. 우리 팀이 작아서 비용 효율을 신경 써야 하는데 좋은 방법이 있을까요?
혹시 프로덕션 환경에서 청킹 쓰고 계신 분 계신가요? 어떤 방식으로 하고 있는지, 그리고 임베딩 모델은 뭘 쓰시는지 궁금합니다.
추천 12 비추천 0
- 이전글LLM 토큰 길이 제한 때문에 답답한데 이게 기술적 한계인가요26.07.19
- 다음글요즘 로컬 LLM 돌려보신 분 계신가요?26.07.17
댓글
4
댓글목록
저도 비슷한 문제 겪었는데, 결국 하이브리드 방식으로 가니까 낫더라고요. 고정 크기에 문장 경계 인식하게 해서 청킹하고, 겹침은 20% 정도만 유지하는 식으로요. 의미론적 청킹은 오프라인에서 배치로 돌리고 온라인은 단순하게 가는 게 비용 효율 좋습니다.
저도 비슷한 문제 겪었는데, 결국 하이브리드 방식으로 가니까 훨씬 나아졌어요. 고정 크기 기본 청킹에 의미론적 병합만 가볍게 얹어서 쓰고 있습니다. 임베딩은 bge-small 썼을 때 성능과 비용 밸런스가 제일 괜찮더라고요. 초반엔 의미론적 청킹 비용이 크게 느껴질 수밖에 없으니까 이런 식으로 타협하면서 시작하는 것도 방법입니다.
저도 비슷한 문제 겪었는데, 결국 하이브리드 방식으로 가니까 제일 낫더라고요. 문서 구조 기반으로 먼저 나누고(섹션, 문단 단위), 그 다음에 고정 크기 + 오버랩 조합으로 처리했어요. 의미론적 청킹은 한 번에 다 하지 말고 배치로 돌리면서 캐싱 활용하면 비용 좀 절감돼요.
임베딩은 프로덕션에서 bge-small이나 multilingual-e5-small 쓰는데 속도 대비 성능이 쏠쏠하더라고요. 작은 팀이면 충분히 커버 가능합니다. 마지막 팁은 검색 결과 재순위 지정(reranking)을 가벼운 모델로 한 번만 해도 중복 문제가 꽤
임베딩은 프로덕션에서 bge-small이나 multilingual-e5-small 쓰는데 속도 대비 성능이 쏠쏠하더라고요. 작은 팀이면 충분히 커버 가능합니다. 마지막 팁은 검색 결과 재순위 지정(reranking)을 가벼운 모델로 한 번만 해도 중복 문제가 꽤
댓글을 작성하려면 로그인이 필요합니다.