저도 비슷한 상황을 겪었는데 결국 sliding window로 겹치게 청킹하는 게 제일 나았어요. 단순 절단보다는 연속성이 훨씬 잘 유지되더라고요. 다만 오버래핑 비율을 어느 정도로 할지가 관건인데 보통 50% 정도에서 괜찮은 결과가 나왔습니다. 아니면 긴 시퀀스는 아예 다른 태스크로 따로 학습시키는 방법도 있더군요.
API연동
LLM 파인튜닝할 때 토큰 길이 제한 어떻게 처리하세요?
요즘 자사 데이터로 오픈소스 모델을 파인튜닝하려고 하는데 문제가 생겼어요. 학습 데이터 중에 컨텍스트 길이를 초과하는 샘플들이 꽤 많거든요. 단순히 잘라내면 정보 손실이 생길 것 같고, 그렇다고 모델의 컨텍스트 윈도우를 늘리려니까 리소스가 너무 많이 들어요.
혹시 이런 경우에 일반적으로 어떻게 처리하세요? 청킹해서 여러 개의 샘플로 나누는 게 정답인지, 아니면 더 좋은 방법이 있는지 궁금합니다. 특히 시퀀스 연속성이 중요한 작업이라서 단순한 청킹이 효과적일지 의문이 네요.
경험 공유해주시면 감사하겠습니다.
혹시 이런 경우에 일반적으로 어떻게 처리하세요? 청킹해서 여러 개의 샘플로 나누는 게 정답인지, 아니면 더 좋은 방법이 있는지 궁금합니다. 특히 시퀀스 연속성이 중요한 작업이라서 단순한 청킹이 효과적일지 의문이 네요.
경험 공유해주시면 감사하겠습니다.
추천 14 비추천 0
- 이전글LLM 비교해본 결과 - 코딩할 땐 Claude가 확실히 낫더라고요26.05.17
- 다음글LLM 토큰 계산할 때 실제로 뭘 기준으로 하세요?26.05.15
댓글
5
댓글목록
저도 비슷한 문제 겪었는데 결국 sliding window로 오버래핑하면서 청킹했어요. 100% 정보 손실은 막을 수 없지만 중요한 부분은 여러 샘플에 걸쳐서 포함되게 하니까 어느 정도는 괜찮더라고요. 시퀀스 연속성이 중요하면 특히 이 방법이 도움될 것 같습니다.
오 저도 같은 문제로 삽질했어요 ㅠㅠ
저도 같은 문제로 고민했는데 결국 슬라이딩 윈도우 청킹으로 처리했어요. 오버랩을 적당히 줘서 시퀀스 연속성을 어느 정도 살리더라고요. 물론 완벽하진 않지만 단순 자르기보다는 훨씬 낫더라고요.
저도 비슷한 상황이었는데 결국 sliding window로 겹치게 청킹하는 게 낫더라고요. 단순 자르기보다 앞뒤 맥락을 조금 겹쳐서 유지하니까 시퀀스 연속성도 어느 정도 살릴 수 있었어요. 물론 중복은 증가하지만 그만한 가치가 있었습니다.
댓글을 작성하려면 로그인이 필요합니다.