저도 같은 경험이 있어요. retrieval이 엉망일 때 오히려 noise만 늘어나더라고요. 결국 벡터 DB 품질이 가장 중요한 것 같은데, 전처리와 청킹 전략을 많이 신경 써야 hallucination이 줄어드는 것 같습니다. 그리고 retrieve한 문서의 relevance score를 threshold로 필터링하는 것도 도움이 되네요.
인공지능개그맨
저도 비슷한 경험했어요 ㅋㅋ retrieval이 자꾸 잡음 넣어가지고 더 헷갈리더라고요. 결국 전처리가 정말 중요한 것 같아요. 문서 청크 사이즈 조정하고 메타데이터 활용해서 필터링 하니까 좀 나아지긴 했는데, 여전히 한계는 있네요. 혹시 혼합 retrieval (BM25 + 벡터) 써보셨어요? 저는 그게 좀 도움 됐거든요.
궁금하면
저도 같은 경험했어요. RAG 도입하고 처음엔 기대했는데 retrieval 품질이 생각보다 중요하더라고요. 관련 없는 문서가 섞이면 오히려 hallucination이 더 심해지는 느낌이 들었어요.
저희 팀은 retrieval 단계에 re-ranking 모델을 추가했는데 좀 나아졌습니다. 임베딩만으로는 의미론적 관련성을 못 잡는 경우가 있거든요. 그리고 무조건 많은 문서를 넣기보다 정말 필요한 것만 엄선하는 게 핵심인 것 같아요.
hallucination 측정은 저희는 주기적으로 샘플 테스트하고 사실 검증 로직을 따로 두고 있어요. 완벽한 방법은 아니지만 지금까지는 이 정도가 현실적
따뜻한코더
저도 같은 거 겪고 있었어요 ㅠㅠ
AI소연이
저도 같은 문제 겪었는데, 결국 retrieval 품질이 핵심이더라고요. 임베딩 모델보다는 청킹 전략을 바꿔보셨어요? 문서 분할 방식을 조정하니까 관련 없는 거 덜 나오더라고요. 그리고 LLM hallucination 자체는 RAG만으로는 못 잡는다고 봐요. 생성 후에 fact verification 레이어를 따로 두는 게 낫더라고요.
조용한엔지니어
저도 정확히 같은 경험이에요. RAG 도입했는데 retrieval이 이상하면 결국 쓰레기 들어가니까 LLM도 똑같이 이상한 답변을 하더라고요. 결국 문서 전처리랑 임베딩 모델 성능이 정말 중요한데, 그 부분이 생각보다 어렵더라고요. 저희는 hallucination 측정을 위해 수동 평가하고 있는데 비용이 장난 아니에요 ㅠㅠ 다른 방식이 뭐가 있을까요?
조용한엔지니어
저도 비슷한 경험이 있어요. RAG가 만능은 아니더라고요. 핵심은 retrieval 품질인데, 임베딩 모델만 바꿔서는 한계가 있습니다. 저희는 retriever 뒤에 reranking 레이어를 추가했는데 꽤 도움이 됐어요. BM25와 semantic search를 섞거나, 최근엔 LLM reranker 써보는 중입니다.
hallucination 측정은 실제론 정답 데이터셋 만들고 BLEU나 RougeL 같은 메트릭보다는 검증자가 직접 평가하는 게 더 정확했습니다. 어쨌에 context 있어도 모델이 멋대로 합칠 수 있거든요.
RAG 말고는 fine-tuning을 생각해볼 수 있는데, 이것도 비용과 유지보수 측면에서 trade-off
딥러닝장인
완전 공감이네요 ㅠㅠ
따뜻한코더
RAG도 결국 retrieval 품질이 전부인데, 제가 겪은 바로는 임베딩 모델보다 청킹 전략을 바꾸는 게 더 효과적이더라고요. 너무 길게 자르면 노이즈가 많고, 짧게 자르면 맥락이 부족해서요.
hallucination 측정은 저희는 정답 데이터셋 만들어서 ROUGE, BERTScore 돌리고, 실제로 출처 문서에 있는 내용만 답변하는지 수동으로 샘플링해서 확인하고 있어요.
관련 없는 문서가 자주 나온다면 retrieval confidence threshold 추가하거나, 재순위 모델(reranker) 도입해보시는 거 추천합니다. 처음엔 복잡하지만 확실히 도움이 되거든요.