저도 같은 문제로 한참 삽질했는데요, 결국 Claude로 넘어갔어요. 100K 토큰이 정말 다르더라고요. 비용이 좀 올라가긴 하지만 청킹으로 인한 정확도 손실이 줄어드니까 결과적으로는 효율적이었어요. RAG도 함께 쓰긴 하는데 Claude 같은 큰 모델과 조합하면 훨씬 낫습니다.
API연동
LLM 토큰 길이 제한 걸릴 때 어떻게 처리하세요?
최근에 긴 문서 분석하는 작업을 하고 있는데 토큰 길이 제한이 자꾸 걸려서 답답하네요. 특히 GPT-4 쓸 때 8K 모델이 아닌 기본 모델 쓰면 금방 튕겨 나가거든요.
지금은 그냥 문서를 직접 청킹해서 여러 번 나눠서 요청을 하고 있는데 이렇게 하면 컨텍스트 손실이 생기는 게 불가피한 것 같아요. 특히 전체 문서의 흐름을 이해해야 하는 작업이면 정확도가 떨어지더라고요. Langchain의 RecursiveCharacterTextSplitter를 써봤는데 이것도 완벽한 건 아닌 것 같고요.
혹시 실무에서 이런 상황 처리하는 좋은 방법이 있으면 궁금합니다. 벡터 DB에 임베딩해서 RAG 방식으로 가는 게 가장 나은 걸까요? 근데 그것도 관련 청크만 뽑아오는 거라 전체 맥락을 완벽히 잡기는 어렵지 않나 싶거든요.
Claude 같은 다른 모델들은 토큰 제한이 더 크다고 들었는데 실제로 써보신 분 있으신가요? 비용이 좀 더 나오겠지만 업무 효율 면에서 낫다면 도입해볼 만할 것 같은데 말이에요.
지금은 그냥 문서를 직접 청킹해서 여러 번 나눠서 요청을 하고 있는데 이렇게 하면 컨텍스트 손실이 생기는 게 불가피한 것 같아요. 특히 전체 문서의 흐름을 이해해야 하는 작업이면 정확도가 떨어지더라고요. Langchain의 RecursiveCharacterTextSplitter를 써봤는데 이것도 완벽한 건 아닌 것 같고요.
혹시 실무에서 이런 상황 처리하는 좋은 방법이 있으면 궁금합니다. 벡터 DB에 임베딩해서 RAG 방식으로 가는 게 가장 나은 걸까요? 근데 그것도 관련 청크만 뽑아오는 거라 전체 맥락을 완벽히 잡기는 어렵지 않나 싶거든요.
Claude 같은 다른 모델들은 토큰 제한이 더 크다고 들었는데 실제로 써보신 분 있으신가요? 비용이 좀 더 나오겠지만 업무 효율 면에서 낫다면 도입해볼 만할 것 같은데 말이에요.
추천 5 비추천 0
- 이전글LLM 파인튜닝할 때 토큰 길이 제한 때문에 고생하신 분?26.07.20
- 다음글LLM의 컨텍스트 윈도우 늘리는 게 정말 성능 향상일까요?26.07.15