저도 같은 고민 많이 했는데요, 결국 문서 청킹이랑 요약 모델을 조합해서 쓰더라고요. 먼저 긴 문서를 의미 있는 단위로 나눈 다음 각 청크마다 요약본을 뽑아서 그걸 컨텍스트로 주는 식으로요. 비용은 좀 들지만 정확도가 훨씬 낫습니다. 아니면 클로드 200K 쓸 때도 있는데 생각보다 비용 차이가 크지 않더라고요.
API연동
LLM 토큰 길이 제한 때문에 답답한데 이거 어떻게 해결하세요?
요즘 GPT-4나 클로드 같은 모델들 써보니까 토큰 길이 제한이 은근 걸리더라고요. 특히 긴 문서 분석하거나 코드 리뷰 요청할 때 자르고 자르면서 작업하다 보니 효율이 떨어지는 것 같아요. 물론 100K 토큰 모델들도 있지만 비용이 좀 되긴 하고요.
혹시 여러분들은 이런 제약을 어떻게 극복하고 계세요? 청킹 전략을 따로 쓰신다거나, 아니면 아예 다른 접근을 하신다든지 궁금합니다. 실무에서 대용량 데이터 다룰 때 팁이나 경험담 있으면 공유해주면 감사하겠습니다.
혹시 여러분들은 이런 제약을 어떻게 극복하고 계세요? 청킹 전략을 따로 쓰신다거나, 아니면 아예 다른 접근을 하신다든지 궁금합니다. 실무에서 대용량 데이터 다룰 때 팁이나 경험담 있으면 공유해주면 감사하겠습니다.
추천 14 비추천 0
- 이전글LLM 파인튜닝할 때 토큰 길이 제한 어떻게 처리하세요?26.05.19
- 다음글LLM 파인튜닝할 때 토큰 길이 제한 어떻게 처리하세요?26.05.16
댓글
5
댓글목록
저도 그거 때문에 자꾸 청킹하게 되더라고요 ㅠㅠ
저도 같은 문제로 고민하다가 요즘은 문서를 주제별로 먼저 요약한 후 핵심 부분만 넘기는 방식으로 하고 있어요. 그리고 API 써서 자동으로 청킹하는 스크립트를 만들어두니까 훨씬 편하더라고요. 비용 부분은 결국 100K 토큰 모델이 장기적으로 낫다는 판단이 서면 써볼 만한 것 같습니다. 혹시 Anthropic의 프롬프트 캐싱 기능도 알아보셨나요? 반복되는 컨텍스트는 캐시되니까 비용을 꽤 절감할 수 있거든요.
저도 비슷한 문제로 고생했는데, 결국 문서를 의미 단위로 먼저 요약한 후 핵심만 추출해서 보내더라고요. 요약 모델 따로 쓰면 토큰 아낄 수 있어요. 아니면 Claude의 100K 모델이 가격 대비는 괜찮은 것 같으니 프로젝트 성격에 따라 고려해볼 만합니다.
저도 같은 고민 많이 하는데, 결국 청킹이 답인 것 같아요. 문서를 의미 있는 섹션별로 나눠서 각각 분석한 다음 요약본끼리 한 번에 처리하는 식으로 하니까 훨씬 나더라고요. API 비용도 오히려 줄어들고요.
아니면 RAG 방식도 괜찮은데, 벡터 DB에 청킹된 데이터 저장해두고 쿼리 관련 부분만 골라서 보내는 거죠. 초기 세팅은 좀 손 가지만 운영 비용으로는 훨씬 효율적입니다. 긴 문서 작업 많으시면 고려해볼 만해요.
아니면 RAG 방식도 괜찮은데, 벡터 DB에 청킹된 데이터 저장해두고 쿼리 관련 부분만 골라서 보내는 거죠. 초기 세팅은 좀 손 가지만 운영 비용으로는 훨씬 효율적입니다. 긴 문서 작업 많으시면 고려해볼 만해요.
댓글을 작성하려면 로그인이 필요합니다.