저도 같은 문제로 한참 삽질했는데요, 결국 Claude로 넘어갔어요. 100K 토큰이 정말 다르더라고요. 비용이 좀 올라가긴 하지만 청킹으로 인한 정확도 손실이 줄어드니까 결과적으로는 효율적이었어요. RAG도 함께 쓰긴 하는데 Claude 같은 큰 모델과 조합하면 훨씬 낫습니다.
API연동
LLM 토큰 길이 제한 걸릴 때 어떻게 처리하세요?
최근에 긴 문서 분석하는 작업을 하고 있는데 토큰 길이 제한이 자꾸 걸려서 답답하네요. 특히 GPT-4 쓸 때 8K 모델이 아닌 기본 모델 쓰면 금방 튕겨 나가거든요.
지금은 그냥 문서를 직접 청킹해서 여러 번 나눠서 요청을 하고 있는데 이렇게 하면 컨텍스트 손실이 생기는 게 불가피한 것 같아요. 특히 전체 문서의 흐름을 이해해야 하는 작업이면 정확도가 떨어지더라고요. Langchain의 RecursiveCharacterTextSplitter를 써봤는데 이것도 완벽한 건 아닌 것 같고요.
혹시 실무에서 이런 상황 처리하는 좋은 방법이 있으면 궁금합니다. 벡터 DB에 임베딩해서 RAG 방식으로 가는 게 가장 나은 걸까요? 근데 그것도 관련 청크만 뽑아오는 거라 전체 맥락을 완벽히 잡기는 어렵지 않나 싶거든요.
Claude 같은 다른 모델들은 토큰 제한이 더 크다고 들었는데 실제로 써보신 분 있으신가요? 비용이 좀 더 나오겠지만 업무 효율 면에서 낫다면 도입해볼 만할 것 같은데 말이에요.
지금은 그냥 문서를 직접 청킹해서 여러 번 나눠서 요청을 하고 있는데 이렇게 하면 컨텍스트 손실이 생기는 게 불가피한 것 같아요. 특히 전체 문서의 흐름을 이해해야 하는 작업이면 정확도가 떨어지더라고요. Langchain의 RecursiveCharacterTextSplitter를 써봤는데 이것도 완벽한 건 아닌 것 같고요.
혹시 실무에서 이런 상황 처리하는 좋은 방법이 있으면 궁금합니다. 벡터 DB에 임베딩해서 RAG 방식으로 가는 게 가장 나은 걸까요? 근데 그것도 관련 청크만 뽑아오는 거라 전체 맥락을 완벽히 잡기는 어렵지 않나 싶거든요.
Claude 같은 다른 모델들은 토큰 제한이 더 크다고 들었는데 실제로 써보신 분 있으신가요? 비용이 좀 더 나오겠지만 업무 효율 면에서 낫다면 도입해볼 만할 것 같은데 말이에요.
추천 10 비추천 0
- 이전글요즘 로컬 LLM 돌려보신 분 계신가요?26.07.17
- 다음글최근에 LLM 양자화 해보신 분들 있어요?26.07.16
댓글
6
댓글목록
저도 비슷한 문제로 고민하다가 결국 Claude 3.5 Sonnet으로 넘어갔어요. 200K 토큰이 정말 게임 체인저더라고요. 비용이 좀 더 나가긴 하지만 청킹 안 해도 되니까 품질 측면에서는 훨씬 낫습니다.
다만 완벽한 건 아니고, 정말 길거나 복잡한 문서면 RAG와 조합해서 쓰는 게 최선인 것 같아요. 전체 맥락이 필요한 부분은 Claude로, 특정 정보 검색은 벡터 DB로 하는 식으로요. 이렇게 하면 꽤 괜찮더라고요.
RecursiveCharacterTextSplitter도 청킹 품질 개선하는 정도라서 근본 해결책은 아니네요.
다만 완벽한 건 아니고, 정말 길거나 복잡한 문서면 RAG와 조합해서 쓰는 게 최선인 것 같아요. 전체 맥락이 필요한 부분은 Claude로, 특정 정보 검색은 벡터 DB로 하는 식으로요. 이렇게 하면 꽤 괜찮더라고요.
RecursiveCharacterTextSplitter도 청킹 품질 개선하는 정도라서 근본 해결책은 아니네요.
저도 같은 문제로 고생했는데 결국 Claude 3.5로 갈아탔어요. 토큰이 20만인데 비용 차이가 생각보다 크지 않더라고요. RAG도 병행하긴 하는데 전체 맥락이 필요한 작업이면 정말 Claude가 낫습니다. 특히 긴 문서의 일관성 유지 면에서요.
저도 같은 문제로 고민했는데 결국 Claude 3 Opus로 바꿨어요. 토큰이 200K라서 웬만한 문서는 통째로 넣어도 되더라고요. 비용이 좀 나지만 청킹 과정에서 손실되는 정확도가 확실히 줄어들었습니다. RAG도 병행하면 더 좋은데 전체 맥락이 필요한 작업에는 토큰 여유가 있는 모델이 진짜 낫습니다.
저도 같은 문제로 고민했는데 결국 Claude 3.5로 갈아탔어요. 토큰이 200K라 청킹 걱정을 거의 안 해도 되더라고요. 가격은 좀 비싸지만 재작업 줄어드는 게 훨씬 크네요. RAG는 정확도가 필요한 작업이면 병행하는 게 낫습니다.
저도 같은 문제로 고생했는데 결국 Claude 3.5 Sonnet으로 넘어갔어요. 토큰이 20만인데 비용 차이가 생각보다 크지 않더라고요. 특히 긴 문서는 한 번에 처리되니까 오히려 API 호출 횟수가 줄어서 비용이 덜 나왔어요.
RAG도 병행하고 있는데 청크 검색만으로는 한계가 있는 게 맞습니다. 저는 문서를 먼저 계층적으로 요약한 다음, 상위 요약본과 관련 청크를 함께 넣는 식으로 하니 맥락 손실이 훨씬 줄었어요. 혼합 방식으로 가보시는 것도 추천합니다.
RAG도 병행하고 있는데 청크 검색만으로는 한계가 있는 게 맞습니다. 저는 문서를 먼저 계층적으로 요약한 다음, 상위 요약본과 관련 청크를 함께 넣는 식으로 하니 맥락 손실이 훨씬 줄었어요. 혼합 방식으로 가보시는 것도 추천합니다.
댓글을 작성하려면 로그인이 필요합니다.