프롬프트만 바꿨는데 RAG 답이 나빠질 때, 먼저 의심할 것
대부분의 경우, 문제는 프롬프트가 아니라 검색(리트리벌) 쪽 불일치에서 시작돼요. 프롬프트를 “더 잘 써봐”로 바꿔도, 애초에 모델이 본 문서가 엉뚱하면 답은 바로잡기 어렵습니다.
결론부터 말하면, RAG 품질이 떨어질 때는 검색 쿼리 리라이팅을 먼저 손보는 게 빠르고 효과적이에요.
왜 프롬프트만 바꾸면 한계가 오나요?
프롬프트는 “어떻게 답할지”를 정해주지만, RAG에서 가장 큰 분기점은 “무슨 문서를 읽게 할지”예요. 여기서 막히면, 생성 단계는 아무리 정교해도 결국 재료가 부족해져요.
사용자는 ‘원인’이 필요한데, 검색은 ‘정의’ 문서를 가져오는 식으로 어긋나요.
문서가 다른 표현(동의어/표기 변형)을 쓰면, 쿼리가 그대로면 회수율이 떨어져요.
“적용법”을 물었는데 “일반론”이 섞이거나, 최신/구버전이 섞여 답이 흐려질 수 있어요.
프롬프트가 바뀌어도, LLM은 나온 근거 문서에 맞춰 답을 만들다 보니 계속 엇나가기 쉽습니다.
바로 비교해보면 감이 와요: 프롬프트 vs 쿼리
| 점검 포인트 | 프롬프트 변경 | 검색 쿼리 리라이팅 |
|---|---|---|
| 영향 지점 | 생성 방식(답의 문장/형식) | 회수 단계(읽히는 문서) |
| 증상 | 답은 그럴듯하지만 “근거가 맞지 않음” | 아예 근거가 약함/관련 문서가 없음 |
| 개선 속도 | 문서가 맞을 때 효과적 | 문서가 틀릴 때 가장 먼저 먹힘 |
그래서 “프롬프트를 바꿔도 그대로다”라는 신호가 나오면, 먼저 리트리벌이 잘 붙는지(검색 쿼리와 문서 표현의 간극)를 봐야 해요.
LLM의 프롬프트는 생성 품질을 좌우하지만, RAG에서는 “문서 회수”가 상위 병목인 경우가 정말 많아요.
적용법 4가지: 검색 쿼리 리라이팅으로 답 품질을 되살리는 방법
아래 4가지는 “사용자 질문 → 검색 쿼리”를 바꾸는 실전 루틴이에요. 프롬프트는 건드려도 되지만, 먼저 이 순서로 테스트해보세요.
의도(질문 목적) 문장으로 재구성하기
사용자 질문이 짧거나 감정/상황이 섞이면 검색이 흔들려요. 쿼리를 “무엇을 알고 싶은지” 기준으로 다시 써서, 검색 엔진이 목적에 맞는 문서를 찾게 만드는 방식이에요.
- 예: “왜 답이 틀리지?” → “RAG에서 답 품질이 떨어지는 원인(검색 실패/근거 부족)을 점검하는 방법”
- 예: “적용법 알려줘” → “OO 기능의 적용 절차와 체크리스트(주의사항 포함)”
이렇게 하면 정의/절차/주의 같은 문서 타입을 더 안정적으로 끌어올릴 수 있어요.
문서에 맞는 키워드로 치환(동의어/표기 변형)
프롬프트가 아무리 친절해도, 검색이 문서가 쓰는 표현을 못 잡으면 근거가 들어오지 않아요. 쿼리에는 “사용자가 쓰는 말”과 “문서가 쓰는 말”을 다리 놓아야 합니다.
- 동의어: “리트리벌” ↔ “검색”, “회수” ↔ “검색 결과 가져오기”
- 표기 변형: “쿼리” ↔ “질문”, “검색 질의”
- 범주 키워드: “원인/체크리스트/가이드/실수/테스트”처럼 문서 카테고리를 유도
핵심은 “추측으로 더 많은 단어를 붙이는 것”이 아니라, 실제로 문서에서 자주 쓰는 표현으로 바꾸는 거예요.
범위 제한을 쿼리에 넣기(최신/환경/대상)
질문이 넓으면 검색도 넓어져서 섞입니다. 그럼 LLM이 답을 정리하는데 더 많은 추론이 들어가고, 결과가 흐려질 가능성이 커져요.
- 환경: “프로덕션 운영”, “개발 단계”, “마이그레이션” 같은 대상 제한
- 범위: “구체적인 설정”, “구현 전 검토”, “오류 로그 기반”처럼 단계 제한
- 시점: “최신 버전/기준 문서”가 필요하면 그 표현을 쿼리에도 반영
특히 운영/비용/성능처럼 범위가 바뀌면 해답도 바뀌는 주제는, 쿼리에서부터 잘라주는 게 좋아요.
확장 쿼리 2~3개로 “후보 문서 다양성” 만들기
한 줄 쿼리에 모든 답을 기대하면 회수율이 흔들릴 때가 많아요. 대신 같은 질문이라도 서로 다른 관점의 쿼리를 2~3개 만들어 후보 문서를 늘려보세요.
- 확장 예시(한 질문에서): “원인 점검” + “해결 절차” + “실수/주의사항”
- 확장 예시(기술 키워드): “검색 쿼리 리라이팅” + “동의어/표기 변형” + “의도 기반 질의”
그리고 최종 생성 전에 “어느 후보 문서가 답에 가장 가까운지”를 간단히라도 점검해야 합니다. (이 과정이 없으면 확장은 그냥 소음이 될 수 있어요.)
쿼리를 길게만 늘리면 검색이 오히려 분산될 수 있어요. 목표는 “더 많이”가 아니라 정확히 더 잘 붙이는 표현을 찾는 겁니다.
실전 적용 체크리스트(바로 테스트할 것만)
- 같은 질문으로도 “회수된 문서”가 매번 다르게 보이는지 확인하기
- 답이 이상할 때, 프롬프트가 아니라 근거 문서가 관련 있는지 먼저 보기
- 리라이팅 전/후로 검색 결과가 “문서 종류(정의/절차/주의)”까지 달라지는지 관찰하기
- 확장 쿼리는 2~3개로 시작해서 불필요한 소음을 줄이기
비슷한 결로 병목을 찾는 팁이 필요하면, AI LLM 호출 속도 느려질 때 먼저 볼 것 글에서 “병목을 어디서 잡는지” 감을 가져오실 수 있어요.
또, 문서가 엉키는 계열 이슈는 MSA 전환 시 데이터 일관성 깨지는 이유 글처럼 “입력/정합성” 관점으로 접근하면 디버깅이 빨라집니다.
자주 나오는 실수 3가지
- 프롬프트만 고치고 검색 결과를 확인하지 않는 것: 근거가 안 맞으면 생성 단계는 계속 비틀려요.
- 동의어를 무작정 추가하는 것: 실제 문서 표현이 아니면 잡음만 늘어납니다.
- 범위 제한을 빼먹는 것: “어느 환경/어느 단계”인지가 없으면 같은 키워드여도 답이 달라질 수 있어요.
정리: RAG 품질이 흔들릴 때의 우선순위
프롬프트가 아니라, 먼저 검색 쿼리 리라이팅으로 근거 문서를 제대로 가져오게 만들면 답 품질이 안정적으로 회복되는 경우가 많아요.
가장 빠른 루틴은 “의도 재구성 → 문서 표현 치환 → 범위 제한 → 확장 쿼리 2~3개” 순서로 짧게 실험하는 겁니다.
자주 묻는 질문
리라이팅을 하면 항상 답이 좋아지나요?
항상은 아니에요. 리트리벌이 이미 충분히 맞을 때는 프롬프트/생성 쪽 개선이 더 클 수 있습니다. 그래서 “답이 나빠진 순간의 회수 문서가 관련 있는지”를 먼저 확인하는 게 좋아요.
쿼리는 길게 만드는 게 더 좋나요?
보통은 길이보다 표현의 적합성이 더 중요해요. 범위를 섞거나 문서 표현과 어긋나면 오히려 검색이 퍼져서 답이 흔들릴 수 있습니다.
확장 쿼리는 몇 개 정도가 적당해요?
처음엔 2~3개로 시작하는 걸 추천해요. 너무 많아지면 후보 문서가 늘어도 정작 관련 근거를 고르기 어려워질 수 있어요.
리라이팅 규칙은 어디까지 자동화해야 하나요?
완전 자동보다 “의도 재구성/범위 키워드/동의어 사전”처럼 통제 가능한 부분부터 단계적으로 넣는 게 안전합니다. 자동화가 커질수록 오탐 쿼리가 늘 수 있어서, 작은 단위 실험 후 확대하는 방식이 좋아요.
