문서 청킹 진짜 악몽이네요 ㅠㅠ
API연동
최근 RAG 기반 LLM 시스템 직접 구축해본 후기
프로젝트에서 GPT 기반으로 RAG 시스템을 직접 구축할 일이 생겨서 지난 3주간 이것저것 만져봤는데 생각보다 복잡하더라고요. 처음에는 간단하게 벡터DB에 임베딩 저장하고 코사인 유사도로 retrieval하면 될 줄 알았는데 현실은 그렇게 단순하지 않았습니다.
가장 큰 문제는 문서 청킹이었어요. 제가 다루는 데이터가 마크다운 형식이었는데 단순하게 토큰 수 기준으로 나누니까 문맥이 완전히 깨지는 거예요. 결국 의미 있는 단위로 분할하는데 꽤 오래 걸렸습니다. 사람이 직접 청크 사이즈를 조정하고 overlap을 실험해야 했거든요.
임베딩 모델도 생각할 게 많더라고요. 처음엔 OpenAI의 text-embedding-3-small을 썼는데 한국어 데이터가 섞여있어서 성능이 아쉬웠어요. 결국 한국어에 최적화된 모델들(upstage, ko-e5 같은)을 테스트해봤는데 확실히 차이가 나더라고요. 비용도 고려해야 하고 지연시간도 봐야 해서 여러 번 교체했습니다.
그리고 실제 운영하면서 깨달은 건데 정말로 중요한 건 retrieval 전략이더라고요. 유사도 기준만으로 다중으로 검색해서 상위 K개를 뽑는 것도 의외로 꽤 효과적이었고, 쿼리 재작성(query rewriting)도 도움이 됐어요. LLM으로 사용자 질문을 다시 정제한 후에 검색하니까 정확도가 올라가더군요.
지금까지의 경험이 맞는지 궁금한데 혹시 이미 이런 식으로 구축해보신 분이 계신가요? 특히 대규모 문서를 다루는 경우 어떤 방식으로 처리하시는지 궁금합니다. 더 나은 방법이 있을 것 같기도 하고요.
가장 큰 문제는 문서 청킹이었어요. 제가 다루는 데이터가 마크다운 형식이었는데 단순하게 토큰 수 기준으로 나누니까 문맥이 완전히 깨지는 거예요. 결국 의미 있는 단위로 분할하는데 꽤 오래 걸렸습니다. 사람이 직접 청크 사이즈를 조정하고 overlap을 실험해야 했거든요.
임베딩 모델도 생각할 게 많더라고요. 처음엔 OpenAI의 text-embedding-3-small을 썼는데 한국어 데이터가 섞여있어서 성능이 아쉬웠어요. 결국 한국어에 최적화된 모델들(upstage, ko-e5 같은)을 테스트해봤는데 확실히 차이가 나더라고요. 비용도 고려해야 하고 지연시간도 봐야 해서 여러 번 교체했습니다.
그리고 실제 운영하면서 깨달은 건데 정말로 중요한 건 retrieval 전략이더라고요. 유사도 기준만으로 다중으로 검색해서 상위 K개를 뽑는 것도 의외로 꽤 효과적이었고, 쿼리 재작성(query rewriting)도 도움이 됐어요. LLM으로 사용자 질문을 다시 정제한 후에 검색하니까 정확도가 올라가더군요.
지금까지의 경험이 맞는지 궁금한데 혹시 이미 이런 식으로 구축해보신 분이 계신가요? 특히 대규모 문서를 다루는 경우 어떤 방식으로 처리하시는지 궁금합니다. 더 나은 방법이 있을 것 같기도 하고요.
추천 14 비추천 0
- 이전글LLM 응답 시간 단축하려고 캐싱 적용했는데 실제 효과가 있네요26.04.04
- 다음글LLM 파인튜닝 vs RAG, 실제로는 어느 쪽이 낫나요?26.03.28
댓글
11
댓글목록
청킹 문제 정말 공감돼요. 저도 비슷한 경험이 있는데 단순 토큰 기준으로 나누니까 테이블이나 리스트 구조가 완전히 망가지더라고요. 결국 LangChain의 RecursiveCharacterTextSplitter 써보고 마크다운 파서도 따로 작성했는데 시간이 많이 걸렸어요.
임베딩 모델 교체도 신경 쓸 게 많네요. 저는 ko-e5-large로 갔는데 text-embedding-3-small보다 한국어 성능은 훨씬 낫지만 응답 속도가 느린 게 문제였어요. 결국 retrieval 정확도와 비용, 레이턴시를 모두 만족시키려니 트레이드오프 고민이 끝이 없더라고요. 계속해서 어떤 결과를 얻으셨는지
임베딩 모델 교체도 신경 쓸 게 많네요. 저는 ko-e5-large로 갔는데 text-embedding-3-small보다 한국어 성능은 훨씬 낫지만 응답 속도가 느린 게 문제였어요. 결국 retrieval 정확도와 비용, 레이턴시를 모두 만족시키려니 트레이드오프 고민이 끝이 없더라고요. 계속해서 어떤 결과를 얻으셨는지
청킹 진짜 그거네요 ㅠㅠ
저도 비슷한 경험을 했는데 청킹이 정말 악몽이더라고요 ㅋㅋ 특히 마크다운처럼 구조가 있는 데이터는 더 그렇고요. 한국어 임베딩도 저는 BAAI의 bge-m3을 써봤는데 ko-e5보다 나았어요. 혹시 retrieval 평가는 어떤 방식으로 하셨나요?
청킹 문제 정말 공감돼요. 저도 처음엔 고정 크기로 나눴다가 semantic chunking으로 바꿨는데 훨씬 낫더라고요. 한국어 임베딩은 정말 차이가 크네요. upstage 모델 써봤는데 OpenAI 기본 모델보다 확실히 좋았습니다. 혹시 retrieval 성능 평가는 어떻게 하셨어요? RAGAS 같은 프레임워크 써보셨나요?
문서 청킹 부분 정말 공감돼요. 저도 비슷한 프로젝트 했는데 처음엔 단순 토큰 분할로 시작했다가 결과물 보고 깜짝 놀랐거든요. 결국 의미 단위로 수동 조정하는데 엄청 시간 걸렸어요.
한국어 임베딩 모델 부분도 유용한 정보네요. OpenAI 모델 쓰다가 한글 성능에 답답한 적 있었는데 ko-e5는 안 써봤네요. 다음 프로젝트에서 꼭 시도해봐야겠습니다. 결국 여러 모델 다 테스트해보는 게 답인 것 같아요.
한국어 임베딩 모델 부분도 유용한 정보네요. OpenAI 모델 쓰다가 한글 성능에 답답한 적 있었는데 ko-e5는 안 써봤네요. 다음 프로젝트에서 꼭 시도해봐야겠습니다. 결국 여러 모델 다 테스트해보는 게 답인 것 같아요.
청킹 문제 정말 공감되네요. 저도 같은 경험을 했는데 단순 토큰 기준이 얼마나 비효율적인지 깨달았어요. 마크다운 구조를 활용해서 헤더 기준으로 나누니까 훨씬 나아졌습니다. 한국어 임베딩 모델 비교도 도움이 되네요. 저는 ko-e5가 가성비가 제일 좋더라고요. 운영 과정에서 또 어떤 문제들이 있었는지 궁금합니다.
문서 청킹 정말 예상 외로 복잡하더라고요 ㅎㅎ 저도 비슷하게 토큰 기반으로 먼저 했다가 의미 단위로 다시 짜게 됐는데 시간이 생각보다 훨씬 더 걸렸어요. 한국어 임베딩 모델 선택도 제 경험상 정말 중요한데 ko-e5는 저도 추천하고 싶네요. 가성비도 좋고 성능도 충분히 괜찮았거든요.
청킹 문제 정말 공감돼요. 저도 마크다운 문서로 할 때 같은 경험했는데 결국 LangChain의 MarkdownHeaderTextSplitter 써보니까 훨씬 낫더라고요. 의미 있는 헤더 기준으로 나눠져서요. 한국어 임베딩 모델은 역시 비용 대비 ko-e5가 괜찮은 것 같아요.
문서 청킹 진짜 생각보다 어렵더라고요 ㅋㅋ 저도 비슷한 경험 있어요
청킹이 진짜 고민이네요 ㅠㅠ 저도 비슷한 경험이 있어서요
댓글을 작성하려면 로그인이 필요합니다.