RAG가 근거를 찾아 답변한다고 해도 서비스가 허용하지 않는 요청까지 처리해야 하는 것은 아니다. 검색 품질과 응답 정책은 서로 다른 설계 문제다.

이번 글은 제공된 Task-4.ipynb의 코드와 저장 출력을 검토한 기록이다. 새 Guardrail을 생성하거나 모델을 호출하지 않았다. 원본의 리소스 식별자와 전체 trace는 공개하지 않는다.

Guardrails는 모델 재학습이 아니다

원본 실습은 허용하지 않을 조언 주제를 정의하고, 내용 필터·금칙어·민감정보·근거성 관련 설정을 함께 구성한다. 이는 모델 가중치를 바꾸는 작업이 아니라 요청과 응답에 적용할 정책을 설정하는 작업이다.

정책 종류 이 실습에서 확인할 관점
주제 정책 서비스가 답하지 않을 요청 범위
내용 필터 입력·출력의 지정 범주
단어 정책 특정 표현을 직접 검사
민감정보 정책 탐지 결과에 따른 차단·가림
근거성 관련 설정 지원되는 호출 경로에서 근거·질문과 응답의 관계 검사

정책을 설정했다는 사실과 특정 호출에서 해당 정책이 실행됐다는 사실은 다르다. 지원되는 모델·호출 경로와 실제 trace를 확인해야 한다.

RAG 요청에는 ID와 버전을 연결한다

다음은 기존 요청 설정에 Guardrail을 연결하는 형태를 보여주는 코드 조각이다. kb_config는 해당 호출용으로 이미 만든 Knowledge Base 설정이며, 이 조각은 자원 생성이나 모델 호출을 포함하지 않는다.

kb_config.setdefault("generationConfiguration", {})[
    "guardrailConfiguration"
] = {
    "guardrailId": guardrail_id,
    "guardrailVersion": guardrail_version,
}

원본 노트북은 이름으로 목록을 검색해 기존 Guardrail을 찾거나 새로 만든다. 하지만 처음 10개만 조회하는 방식으로는 목록 뒤의 동일 이름 자원을 놓칠 수 있다. 운영 설정에서는 ID를 명시적으로 관리하거나 페이지네이션과 선택 조건을 처리해야 한다.

저장 trace에는 DRAFT 버전이 사용됐다. 초안은 바뀔 수 있으므로 재현 가능한 비교나 배포에서는 설정 스냅샷인 버전을 만들고 애플리케이션이 사용할 버전을 고정하는 접근이 적절하다. 태그에 production이라고 적었다고 운영 검증이 완료된 것은 아니다.

저장된 결과가 보여주는 범위

원본에는 동일한 주제의 질문에 대해 Guardrail 없이 호출한 응답과, Guardrail을 연결한 응답이 저장돼 있다. 전자는 요청에 대한 추천을 제공하고 후자는 설정된 안내 문구를 반환한다.

이것으로 해당 두 호출의 사용자 응답이 달랐다는 점은 확인할 수 있다. 그러나 한 사례만으로 모든 변형 질문이 차단되거나 정상 질문이 모두 통과한다고 결론낼 수는 없다.

뒤의 셀은 Knowledge Base 통합 호출이 아니라 bedrock-runtime.invoke_model에 trace="ENABLED"를 설정한 별도의 직접 모델 호출이다. 이 trace를 앞선 RAG 요청의 내부 추적으로 취급하면 안 된다.

trace에서는 입력과 출력을 구분한다

직접 호출의 저장 trace에는 모델이 만든 원래 출력이 있고, 출력 평가 영역의 주제 정책에 BLOCKED가 기록돼 있다. 사용자에게는 대신 설정된 안내 문구가 전달됐다.

이는 “모델이 처음부터 그 답을 생성하지 않았다”와 다르다. 이 기록에서는 생성된 출력에 정책이 개입한 흔적을 확인할 수 있다.

또한 해당 trace의 contextualGroundingPolicyUnits는 0이다. 정책 설정에 근거성 항목이 있다는 이유로 이 직접 호출에서 근거성 검증까지 수행됐다고 설명해서는 안 된다. 질문과 참조 근거가 없는 단순 호출과 RAG 호출의 실행 조건도 다르다.

확인할 필드·정보 이유
호출 경로와 요청 ID RAG 요청과 직접 호출을 구분
적용 Guardrail 버전 같은 정책으로 비교했는지 확인
입력·출력 평가 위치 어느 단계에서 개입했는지 확인
탐지 정책과 action 차단의 구체적 이유 확인
처리 시간·사용량 정책 적용의 지연과 비용 확인

전체 trace에는 차단된 원본 내용과 식별자가 들어갈 수 있다. 사용자 화면에 그대로 노출하지 않고 접근 통제와 보관 정책을 적용해야 한다. 진단에 필요한 정보만 추출하는 방식이 좋다.

검색 문서의 권한을 대신하지 않는다

AWS의 Knowledge Bases 문서는 이 통합 경로에서 Guardrails가 입력과 생성 응답에 적용되며, 런타임에 검색된 참조 자료에는 적용되지 않는다고 명시한다.

따라서 Guardrail을 연결했다고 모든 검색 문서가 사전에 정제됐다고 가정하면 안 된다. 문서별 접근 권한은 검색·자료 전달 경로에서 따로 통제해야 한다. 개인정보 가림도 이미 로그나 다른 구성 요소에 전달된 내용을 되돌려 지우는 기능은 아니다.

검색 자료 안에 평가자나 생성 모델을 겨냥한 지시가 들어가는 문제 역시 따로 점검할 필요가 있다. 관련 원리는 프롬프트 주입 글에서 다뤘다.

차단 성공과 정상 응답을 함께 테스트한다

실제 적용 시에는 가상의 도서관 안내 서비스처럼 민감한 원문 없이도 정책 경계를 테스트할 수 있다.

테스트 종류 예시의 목적
정상 이용 안내 허용 질문을 과도하게 차단하지 않는지
금지 주제의 직접 요청 기본 차단 동작
같은 뜻의 다른 표현 단어 매칭만 확인한 것은 아닌지
금지 표현을 인용한 설명 정상 문맥과 요청을 구분하는지
민감정보가 섞인 요청 필요한 가림·차단 동작
근거에 없는 질문 근거 부족 응답과 정책 차단을 구분

“모름”, “검색 결과 없음”, “정책상 거절”, “API 오류”를 같은 응답 상태로 묶으면 운영 중 원인을 구분하기 어렵다. 사용자 안내는 간단하게 제공하더라도 내부 기록에는 이유를 나눠 남기는 편이 좋다.

차단률만 높이는 것은 충분하지 않다. 허용해야 할 질문을 막는 비율과 금지 요청을 놓치는 비율을 함께 봐야 한다.

평가와 정책은 역할이 다르다

이전 편의 RAGAS 평가는 답변의 근거성과 관련성 등 품질을 점검하는 도구다. Guardrails는 설정한 정책을 요청과 응답에 적용한다. 어느 쪽도 단독으로 전체 서비스의 정확성이나 안전성을 보장하지 않는다.

이 시리즈에서 남겨야 할 기록은 일관된다. 어떤 질문으로 무엇을 검색했고, 그 근거로 무엇을 생성했으며, 어떤 평가와 정책을 거쳐 사용자에게 무엇을 보여줬는지 연결돼 있어야 한다.

그 연결이 있어야 모델 문제, 검색 문제, 평가 문제, 정책 문제를 구분해 개선할 수 있다.

참고 자료