RAG 실패의 상당수는 모델이 아니라 인덱싱 설계에서 납니다. 청크를 너무 잘게 나누면 문맥이 끊겨 “맞는 문장”이 있어도 질문이 요구하는 조건을 놓치고, 너무 크게 나누면 검색이 둔해지고 토큰 비용만 올라갑니다. 매뉴얼·정책·표·코드처럼 문서 유형별로 청크 크기와 오버랩을 다르게 두는 편이 안전합니다.
제목·섹션 경계를 무시한 기계적 분할도 자주 문제입니다. 표가 중간에 잘리거나, “예외 조항”이 다음 청크로 밀리면 모델은 자신 있게 틀린 답을 냅니다. 가능하면 헤딩 단위로 자르고, 표·리스트는 한 덩어리로 유지하세요. 오버랩은 문장 중간이 아니라 섹션 경계 근처에서 거는 것이 재현성이 좋습니다.
메타데이터 없는 임베딩은 운영에서 거의 반드시 문제가 됩니다. 출처 URL, 문서 버전, 부서, 권한 등급, 갱신일, 언어가 없으면 “맞는 문장”을 골라도 누구에게 보여줄지, 얼마나 신뢰할지 판단할 수 없습니다. 답변 UI에는 출처 링크와 갱신일을 함께 노출하세요. 사용자가 원문을 열어볼 수 있어야 환각을 스스로 걸러냅니다.
권한 필터를 검색 후에만 걸면 상위 결과가 전부 걸러져 빈 답이 늘어납니다. 인덱싱 단계부터 열람 범위를 메타데이터로 넣고, 검색 쿼리와 함께 필터링하는 쪽이 운영이 쉽습니다. 임시로 전체 공개 인덱스를 만든 뒤 나중에 권한을 붙이려는 계획은 대개 재인덱싱 비용으로 되돌아옵니다.
평가 없이 파라미터만 튜닝하는 것도 흔한 함정입니다. 질문 20~50개짜리 골든셋을 만들고, 검색 적중·답변 정확·출처 적합을 각각 점수화하세요. top-k, 리랭커, 온도를 바꿀 때마다 같은 세트로 비교하지 않으면 “감으로 좋아진 것 같다”만 남습니다.
운영 팁: 실패 케이스를 주간으로 모아 청크·메타데이터·권한 규칙을 고칩니다. 모델 교체는 그 다음입니다. 인덱스가 깨끗하지 않은 상태에서 더 큰 모델로 바꿔도 비용만 늘고 체감 품질은 거의 안 오르는 경우가 많습니다.
