댓글목록
저도 비슷한 경험 있는데, context 늘렸을 때 오히려 성능이 떨어지는 건 llama2 같은 작은 모델에서는 흔한 문제더라고요. 모델이 관련 정보와 노이즈를 구분하는 능력이 떨어져서 그런 것 같아요.
제 경우엔 무조건 context를 크게 가져가기보다 retriever에서 정말 관련성 높은 문서만 상위 3~5개만 뽑아서 집어넣는 식으로 바꿨는데 훨씬 낫더라고요. 32k 다 쓸 필요 없이 필요한 만큼만 정제된 정보를 주는 게 포인트인 것 같습니다.
혹시 BM25랑 벡터 검색 결과를 합칠 때 가중치 설정은 어떻게 하고 계세요? 거기
그거 잘알려진 현상이네요. Lost in the Middle 논문 참고하면 도움될 거 같아요. Context 늘리면 모델이 중간에 있는 정보를 무시하는 경향이 있거든요. 4k에서 성능이 좋았던 건 retriever가 뽑아준 상위 문서들이 실제로 관련성 높은 거였기 때문일 수 있어요.
그래서 해결 방법으로는 context 크기 자체보다는 retriever 품질 개선이 더 중요합니다. BM25 + 벡터 검색 쓰고 계신데 reranker 추가해보세요. 예를 들어 cross-encoder 기반 reranker 쓰면 상위 k개만 정말 관련성 높은 걸 뽑아줄 수 있어요. llama2 13b는 메모리도 한정적이니 오히려 컨텍스트는
저도 비슷한 경험 했는데 제 경우엔 retriever에서 가져오는 문서 개수를 줄였을 때 괜찮아졌어요. context window를 크게 하면 관련도 낮은 문서까지 섞여서 모델이 헷갈리는 것 같더라고요. BM25랑 벡터 검색 조합이면 retrieval 단계에서 top-k 값을 조정해보시는 게 어떨까요? 저는 32k로 쓸 때 10개에서 5개로 줄였더니 성능이 올라갔거든요. 아니면 retrieved documents를 relevance score로 필터링하는 방식도 괜찮습니다.
저도 비슷한 경험 있어요. Context 늘리면 관련성 떨어진 문서까지 포함될 확률이 높아지더라고요. Retriever에서 top-k 개수 줄이거나 similarity threshold 올려보세요. 그리고 reranker 추가하는 것도 도움 됩니다.
저도 비슷한 경험 있어요. Context 늘렸을 때 lost in the middle 현상 때문에 오히려 성능이 떨어질 수 있거든요. Llama2 같은 경우 특히 그런 경향이 있더라고요. 혹시 retrieval한 문서들의 순서를 최신 순서대로 재정렬해봤어요? 그리고 각 청크의 크기도 확인해보시길 권해요. Context window가 크면 관련도 낮은 문서까지 포함될 확률이 높아져서 모델이 헷갈릴 수 있습니다. 저는 top-k를 줄이고 similarity threshold를 올려서 해결했어요.
context window 크기보다는 retrieval 단계에서 가져오는 문서 개수가 문제일 수 있어요. 32k로 늘렸을 때 더 많은 관련 없는 문서들을 함께 넣고 있지 않은가 싶은데요. BM25는 특히 그럴 수 있거든요.
llama2 13b 같은 작은 모델은 실제로 noise에 민감해서 관련 문서 상위 5~10개 정도로 제한하고, 불필요한 context는 필터링하는 게 더 효과적일 수 있습니다. 혹은 context 안에서 관련도가 높은 정보를 먼저 배치하는 방식도 도움이 될 거 같네요.
context window 크면 noise retrieval 문제가 생길 수 있더라고요. 저도 비슷한 거 겪었는데 top-k 수를 줄이거나 retriever 점수로 필터링을 더 엄격하게 하니까 나아졌어요. llama2라면 attention 메커니즘상 긴 컨텍스트에서 산만해질 수 있으니 한번 확인해보세요.
Context window 크기 자체보다는 retriever에서 던져주는 문서 개수를 체크해보세요. BM25 + 벡터 검색 조합이면 상위 k개를 뽑는데, 관련 없는 문서까지 많이 섞여 들어가면서 모델이 헷갈리는 경우가 많거든요.
제가 비슷한 상황 겪었는데 retriever에서 top-5만 뽑도록 줄였더니 32k window에서도 성능이 올라갔어요. 아니면 reranker를 추가해서 검색 결과 순서를 다시 매기는 것도 도움이 됩니다.
llama2 13b는 긴 문맥 처리가 그리 강한 편은 아니라서, context가 길어질수록 중간에 있는 정보를 놓치는 경향이 있어요. 혹시 현재 retriever 설정에서 몇
저도 비슷한 경험 있어요. context window 늘렸을 때 noise가 섞이면서 모델이 집중을 못 하는 경우가 있더라고요. retriever 상위 문서 수를 줄이거나 reranking 단계를 추가해보세요. 저는 그렇게 하니까 32k에서도 성능이 올라갔습니다.
llama2는 긴 context에서 needle in haystack 문제가 있는 걸로 알려져 있더라고요. 32k 넣으면 중간 부분 정보를 잘 못 잡아내는 경향이 있어요. context는 그냥 4k 유지하고 retriever에서 더 정확한 문서만 먼저 뽑아내는 쪽으로 가면 어떨까요. BM25 가중치 조정해보시는 것도 도움될 겁니다.
저도 비슷한 경험이 있는데, context 크기보다는 retriever가 가져오는 문서의 질이 더 중요한 것 같아요. BM25 + 벡터 검색 조합이면 retrieval 단계에서 노이즈가 섞여 올 가능성이 높거든요. 혹시 top_k 값은 그대로 두고 window만 늘린 건가요? 저는 window 늘릴 때 retrieval 점수 기준을 더 높여서 상위 문서만 넣도록 조정했더니 나아졌어요. 아니면 reranker 추가하는 것도 방법입니다.
저도 비슷한 경험했는데, context 크면 retriever가 가져온 문서들 사이에 노이즈가 많아져서 모델이 헷갈리더라고요. BM25 + 벡터 조합이면 상위 k개 결과만 엄선해서 넘기는 게 낫더라고요. 저는 top-5 정도로 제한했더니 32k에서도 잘 되더라고요.
오 저도 비슷한 경험했는데 prompt injection 때문일 수도 있어요
저도 context 늘렸다가 성능 떨어진 적 있어요. 보통 retriever에서 관련도 낮은 문서까지 많이 들어와서 그런 것 같더라고요. 혹시 top-k 값도 함께 늘리셨나요?
저도 비슷한 경험 있어요. Context 늘렸을 때 오히려 noise가 많아져서 성능이 떨어지더라고요. 제 경우엔 retriever에서 top-k 개수를 줄이거나 relevance threshold를 높여서 더 정확한 문서만 넣으니 괜찮았어요. llama2는 특히 긴 context에서 중간 부분 정보를 놓치는 경향이 있다고 알려져 있으니까, prompt 구조를 다시 한 번 검토해보시는 것도 도움이 될 것 같습니다.
오 저도 비슷한 거 겪었어요 ㅠㅠ
저도 비슷한 경험 있어요. Context 늘렸을 때 noise 때문에 성능이 떨어지는 거 맞더라고요. Retriever에서 top-k 개수를 줄이거나, chunk 크기를 더 작게 해서 precision을 높여보세요. 그리고 Llama2 13b는 긴 context에서 attention 분산이 있을 수 있으니 prompt를 더 명확하게 구성하는 것도 도움이 됩니다.
저도 비슷한 경험 있어요. Context window 늘린다고 무조건 좋아지는 건 아니더라고요. 특히 llama2 같은 경우 긴 컨텍스트에서 중간 부분을 놓치는 "lost in the middle" 현상이 있거든요.
retriever에서 나온 문서들을 단순히 다 때려박기만 하면 관련도 낮은 정보가 섞여서 모델이 헷갈리는 것 같아요. 저는 검색된 청크들을 재정렬하거나 요약해서 줄이는 방식으로 개선했습니다. 아니면 context window는 그대로 두고 retriever 성능을 높이는 게 더 효과적일 수도 있어요.
저도 비슷한 경험 있어요. Context window 크기와 성능은 직선적 관계가 아니더라고요. 특히 llama2 13b 정도 사이즈면 더 그런 것 같습니다.
제 경험상 문제는 두 가지였어요. 첫째, retriever에서 가져온 문서들의 quality 때문이었어요. BM25랑 벡터 검색 결합할 때 관련도 낮은 청크들도 함께 들어가면서 모델이 노이즈에 헷갈리는 거죠. 둘째는 llama2가 실제로 긴 context를 효과적으로 활용하지 못하는 경향이 있다는 걸 깨달았어요.
제 해결책은 context window는 16k 정도로 타협하고, retriever 파이프라인을 더 튜닝했습니다. 문서 청크 크기 조정, 중복 제
