저도 비슷한 문제로 고민했는데 결국 벡터 디비가 현실적이더라고요. 클로드 같은 긴 컨텍스트 모델도 써봤는데 비용이 장난 아니고, 실무에선 RAG 방식이 훨씬 효율적인 것 같습니다. 요즘 Llama 2 70B에 RoPE 보간 적용한 버전도 있긴 한데 여전히 한계가 있어서 결국 임베딩 + 벡터DB 조합으로 가는 게 최선인 것 같아요.
프롬프트
토큰 길이 제한 없이 긴 문맥 처리하는 모델 어떤 거 써보셨어요?
요즘 프로젝트에서 긴 문서를 한 번에 분석해야 하는데 보통의 트랜스포머 모델들은 토큰 제한이 있어서 자르고 자르고 하는 게 너무 비효율적이더라고요. 청크 단위로 나눠서 처리하면 문맥 손실이 생길 수밖에 없고요.
혹시 이런 문제를 잘 해결하는 모델 사용해보신 분 있나요? RoPE 위치 보간이나 ALiBi 같은 방식도 봤는데 실제로 얼마나 효과가 있는지 궁금합니다. 아니면 그냥 벡터 디비로 처리하는 게 더 현실적인가요?
혹시 이런 문제를 잘 해결하는 모델 사용해보신 분 있나요? RoPE 위치 보간이나 ALiBi 같은 방식도 봤는데 실제로 얼마나 효과가 있는지 궁금합니다. 아니면 그냥 벡터 디비로 처리하는 게 더 현실적인가요?
추천 9 비추천 0
- 이전글LLM 파인튜닝할 때 QLoRA 말고 다른 방법 써보신 분?26.09.09
- 다음글요즘 LLM 파인튜닝 해보신 분들 경험담 듣고 싶어요26.09.06
댓글
3
댓글목록
저도 비슷한 상황 겪었는데 결국 벡터 DB 조합이 가장 현실적이더라고요. RoPE 보간이나 ALiBi 시도해봤는데 솔직히 기대만큼 안 돼요. 토큰을 3-4배 늘릴 수 있어도 정확도가 떨어지는 느낌이 있거든요.
실무에선 임베딩 기반으로 청크 검색한 다음 상위 K개만 넘기는 방식이 훨씬 안정적이었습니다. 물론 전체 문맥은 못 보지만 필요한 부분은 잘 캐치되더라고요. Llama 2 fine-tuning해서 긴 문맥 처리하는 것도 시도해봤는데 투자 대비 효과가 애매했어요. 어떤 도메인이신지에 따라 다를 수도 있겠네요.
실무에선 임베딩 기반으로 청크 검색한 다음 상위 K개만 넘기는 방식이 훨씬 안정적이었습니다. 물론 전체 문맥은 못 보지만 필요한 부분은 잘 캐치되더라고요. Llama 2 fine-tuning해서 긴 문맥 처리하는 것도 시도해봤는데 투자 대비 효과가 애매했어요. 어떤 도메인이신지에 따라 다를 수도 있겠네요.
저도 비슷한 상황을 겪었는데 결국 벡터 DB 조합이 제일 현실적이더라고요. 긴 문서를 통째로 넘기는 것보다 관련성 높은 청크만 선별해서 넣으니까 문맥 손실도 줄이고 비용도 절감되었습니다.
RoPE 보간이나 ALiBi는 이론상으로는 좋은데 실무에선 미묘하더라고요. 제한을 늘려도 질이 완벽하진 않아서요. 요즘 나오는 모델들(Claude, GPT-4 Turbo 같은)은 자체 컨텍스트 윈도우가 크긴 한데, 가격이 그만큼이라 비용 대비로 따지면 벡터 DB가 더 효율적입니다. 특히 같은 문서를 반복해서 처리해야 한다면 더욱요.
RoPE 보간이나 ALiBi는 이론상으로는 좋은데 실무에선 미묘하더라고요. 제한을 늘려도 질이 완벽하진 않아서요. 요즘 나오는 모델들(Claude, GPT-4 Turbo 같은)은 자체 컨텍스트 윈도우가 크긴 한데, 가격이 그만큼이라 비용 대비로 따지면 벡터 DB가 더 효율적입니다. 특히 같은 문서를 반복해서 처리해야 한다면 더욱요.
댓글을 작성하려면 로그인이 필요합니다.