저도 그 문제 겪었는데 정말 짜증나더라고요 ㅋㅋ 결국 청킹이 답인 것 같아요.
파인튜닝
LLM 컨텍스트 윈도우 늘리는 것만으로는 부족하다는 걸 깨달았어요
최근에 프로젝트에서 긴 문서를 여러 개 한 번에 처리해야 할 일이 생겼는데, 무작정 큰 컨텍스트 윈도우를 가진 모델을 쓰면 된다고 생각했어요. 근데 실제로 써보니까 그게 아니더라고요.
클로드 200K, GPT-4 터보 128K 이런 식으로 컨텍스트 윈도우가 크다고 해서 성능이 선형으로 올라가지 않는다는 걸 느꼈습니다. 특히 문서가 30개 이상 들어가면 중간에 있는 정보들을 자꾸 놓치더라고요. 이게 "잃어버린 중간" 현상이라고 들었는데, 큰 컨텍스트도 이 문제를 완전히는 못 피하는 것 같습니다. 그래서 요즘은 청크 단위로 나눠서 먼저 요약한 후에 최종 프롬프트에 넣는 방식으로 바꿨어요.
또 하나는 토큰 길이가 늘어날수록 비용도 확 올라간다는 거죠. 10K 토큰 짜리 프롬프트를 매번 돌리면 테스트 비용만 엄청납니다. 회사에서 쓸 때는 더 심할 거고요. 그래서 실무에서는 컨텍스트 최적화가 정말 중요한 것 같아요.
혹시 다른 분들도 비슷한 경험 하셨나요? 특히 대량의 문서를 처리할 때 어떤 방식으로 프롬프트를 구성하시는지 궁금합니다. 래그(RAG) 쓰시는 분들은 그걸로 해결되나요?
클로드 200K, GPT-4 터보 128K 이런 식으로 컨텍스트 윈도우가 크다고 해서 성능이 선형으로 올라가지 않는다는 걸 느꼈습니다. 특히 문서가 30개 이상 들어가면 중간에 있는 정보들을 자꾸 놓치더라고요. 이게 "잃어버린 중간" 현상이라고 들었는데, 큰 컨텍스트도 이 문제를 완전히는 못 피하는 것 같습니다. 그래서 요즘은 청크 단위로 나눠서 먼저 요약한 후에 최종 프롬프트에 넣는 방식으로 바꿨어요.
또 하나는 토큰 길이가 늘어날수록 비용도 확 올라간다는 거죠. 10K 토큰 짜리 프롬프트를 매번 돌리면 테스트 비용만 엄청납니다. 회사에서 쓸 때는 더 심할 거고요. 그래서 실무에서는 컨텍스트 최적화가 정말 중요한 것 같아요.
혹시 다른 분들도 비슷한 경험 하셨나요? 특히 대량의 문서를 처리할 때 어떤 방식으로 프롬프트를 구성하시는지 궁금합니다. 래그(RAG) 쓰시는 분들은 그걸로 해결되나요?
추천 9 비추천 0
- 이전글Llama 3.1 70B 로컬에서 돌려보니 이전 모델과 확실히 다르네요26.08.11
- 다음글최근 오픈소스 LLM으로 로컬 RAG 구축해본 분 계신가요?26.08.10