RAG 문서 오염 공격, 왜 output filter보다 ingestion 통제가 중요한가

Hacker News에서 주목받은 Amine Raji의 실험은 document poisoning이 작은 RAG stack에서도 얼마나 실용적으로 작동하는지 보여준다. 그는 LM Studio, Qwen2.5-7B-Instruct, ChromaDB, 그리고 5개의 정상 문서만 있는 local knowledge base를 사용해 세 개의 가짜 “정정 문서”를 삽입했다. 그 뒤 회사 실적을 묻는 평범한 질문을 던지자, 시스템은 실제 Q4 2025 매출인 $24.7M 대신 조작된 $8.3M 수치와 구조조정 이야기까지 자신 있게 답하기 시작했다.

핵심은 이 공격이 prompt를 탈취하거나 모델을 jailbreak하지 않아도 된다는 점이다. 승부는 더 앞단, 즉 retrieval과 source weighting에서 난다. 가짜 문서들은 합법적인 재무 문서와 비슷한 어휘를 쓰면서도 “CFO-approved correction”, “board update” 같은 권위 표현을 덧붙여 모델이 잘못된 문서를 더 신뢰하도록 유도한다. 작성자 측정에서는 20회 중 19회가 성공했고, 블로그는 이런 지속성이 일회성 prompt injection보다 운영상 더 위험할 수 있다고 설명한다. 다만 작성자도 5문서 corpus는 공격자에게 유리한 best-case라고 분명히 적었다.

가장 흥미로운 부분은 방어 결과다. Raji는 prompt hardening과 output monitoring은 일부 완화 효과만 있었고, ingestion 단계에서 새 문서의 semantic overlap을 검사하는 embedding anomaly detection이 standalone 기준 성공률을 95%에서 20%로 낮췄다고 주장했다. 다섯 가지 방어 레이어를 함께 켜면 잔여 성공률은 10%까지 떨어졌다고 한다. 즉 질문은 “모델이 나쁜 답을 거부할 수 있나”보다 “누가 knowledge base에 쓰기 권한을 갖고 있고, 그 쓰기를 어떻게 검증하나”로 이동한다.

Hacker News 댓글은 이 전제를 집요하게 짚었다. 일부는 knowledge base write access 자체가 이미 특권적이라고 했고, 다른 이들은 citation UX나 provenance를 더 엄격히 만들면 이런 실패를 더 빨리 발견할 수 있다고 말했다. 그래도 결론은 분명하다. RAG가 Confluence, Slack, SharePoint, 내부 문서 파이프라인과 연결될수록 ingestion은 별도의 attack surface가 된다. 원문: Amine Raji. 커뮤니티 반응: Hacker News.