저도 비슷한 문제 겪었는데 슬라이딩 윈도우로 50% 오버랩 주면서 자른 후 학습했더라고요. 생각보다 나쁘지 않았어요. 요약은 정말 정보 손실이 심하긴 한데, 혹시 청킹 + retrieval 방식으로 가는 것도 고려해볼 만할 것 같습니다. 파인튜닝이 아니라 RAG로 구성하면 컨텍스트 제한이 덜 문제가 되거든요.
API연동
LLM 파인튜닝할 때 토큰 길이 제한 때문에 고민이에요
요즘 특정 도메인용 LLM을 파인튜닝하려고 하는데, 학습 데이터 중에 긴 문서들이 많더라고요. 모델의 컨텍스트 윈도우가 4K인데 실제 문서는 8K~15K 정도 나가는 경우가 많아서 어떻게 처리할지 고민이 됩니다.
지금 생각해본 방법이 크게 나눠서 슬라이딩 윈도우로 자르기, 또는 요약 후 학습하는 방식인데 둘 다 뭔가 정보 손실이 있을 것 같아요. 혹시 다들 어떻게 처리하시나요? 아니면 그냥 모델 크기를 줄여서 라마 같은 걸 쓰는 게 나을까요?
지금 생각해본 방법이 크게 나눠서 슬라이딩 윈도우로 자르기, 또는 요약 후 학습하는 방식인데 둘 다 뭔가 정보 손실이 있을 것 같아요. 혹시 다들 어떻게 처리하시나요? 아니면 그냥 모델 크기를 줄여서 라마 같은 걸 쓰는 게 나을까요?
추천 9 비추천 0
- 이전글요즘 로컬 LLM 돌려보신 분 있나요? 성능이 생각보다네요26.10.13
- 다음글LLM 파인튜닝 비용이 점점 커지는데 뭔가 덜 비싼 방법 없을까요26.10.11
댓글
2
댓글목록
저도 비슷한 문제 겪었는데, 저는 결국 슬라이딩 윈도우 방식으로 갔어요. 중복도 어느 정도 포함시키니까 컨텍스트 손실이 생각보다 덜하더라고요. 요약은 정보 손실이 정말 심해서 추천은 안 하네요.
아니면 요즘은 4K보다 큰 컨텍스트 윈도우 모델들이 많으니까 처음부터 8K 이상 지원하는 모델로 파인튜닝하는 것도 고려해볼 만합니다. 학습 비용이 올라가긴 하지만 데이터 손실을 피할 수 있어요.
아니면 요즘은 4K보다 큰 컨텍스트 윈도우 모델들이 많으니까 처음부터 8K 이상 지원하는 모델로 파인튜닝하는 것도 고려해볼 만합니다. 학습 비용이 올라가긴 하지만 데이터 손실을 피할 수 있어요.
댓글을 작성하려면 로그인이 필요합니다.