랭체인(LangChain) 삽질 후기: RAG 구현하면서 느낀 점
RAG 시스템 만들려고 랭체인 썼는데, 문서 분할(chunking)부터 막혔음.
1. RecursiveCharacterTextSplitter로 500자씩 자르니까 문맥 끊겨서 검색 품질 개판
2. 임베딩 모델은 bge-large-ko vs Korean RoBERTa 고민하다가 bge 씀
3. retriever에 FAISS vs Chroma 중 FAISS가 더 빨라서 선택
결론: 랭체인 자체는 편한데, chunk 전략이 진짜 중요함. 나는 markdown 헤더 기준으로 나누니까 훨씬 낫더라.
혹시 다른 접근법 쓰는 사람 있음?
9 개의 답변
ㅇㅈ chunk가 젤 어렵지
오 markdown 헤더 기준은 생각 못했네. 나는 semantic chunking 써봤는데 꽤 괜찮았음. 문장 단위로 자르는 것보다 훨씬 자연스러워짐.
bge-large-ko vs Korean RoBERTa 비교해보신 분? 나는 RoBERTa가 한국어는 더 낫다고 들었는데
이거 맞음ㅋㅋ 나도 처음에 recursive splitter 썼다가 개망함. 헤더 기준으로 바꾸니까 검색 정확도 확 올라감. chunk size 1000에 overlap 200 정도 주니까 딱이더라.
글쎄 난 LangChain 안 쓰고 그냥 llama_index 씀. 랭체인 너무 추상화 많아서 디버깅 빡셌음.
출처 있음? FAISS가 Chroma 보다 진짜 빠른건지 궁금
저는 chunk할 때 nltk sentence tokenizer 쓰고 문장 단위로 자른 다음에 임베딩 돌렸는데, 문맥 유지 잘됨. 500자 기준은 너무 짧긴 하죠.
동의 안 됨. recursive splitter도 쓰기 나름임. overlap 적절히 주고 section 단위로 metadata 붙이면 꽤 쓸만함. 근데 헤더 기준도 시도해볼게 ㅇㅇ
와 나 완전 공감. 나는 아예 chunk 스트레스에 LangChain 포기하고 HuggingFace 파이프라인으로 직접 짰음. 근데 결국엔 LlamaIndex 가더라고. 랭체인은 초기엔 편한데 나중에 튜닝하려면 빡셈.