- Authors
- Name
문제 정의
RAG 평가와 Tool Calling 가드레일의 핵심 실패는 “정확도 평균”만 보고 안전성과 조작 저항성을 검증하지 않는 것이다.
아키텍처/원리
- Tool 호출은 권한 모델(allowlist, argument schema, rate limit)을 먼저 정의한다.
- RAG 평가는 retrieval·grounding·final answer를 분리 측정한다.
- 온라인에서는 휴리스틱이 아니라 policy engine으로 차단한다.
구현 예시 1
guardrails:
tool_allowlist: [weather.get, calendar.read]
max_tool_calls: 3
pii_redaction: true
citation_required: true
구현 예시 2
def validate_tool_call(name,args):
allowed={"weather.get","calendar.read"}
if name not in allowed:
raise PermissionError("blocked tool")
if len(str(args))>2000:
raise ValueError("arg too large")
구현 예시 3
SELECT prompt_attack_type, avg(blocked::int) AS block_rate
FROM redteam_runs
GROUP BY 1 ORDER BY 2 DESC;
구현 예시 4
name: rag-eval
on: [push]
jobs:
eval:
runs-on: ubuntu-latest
steps:
- run: python eval/retrieval.py --k 5
- run: python eval/grounding.py --citation-th 0.9
- run: python eval/safety.py --policy guardrails.yaml
운영 팁
- 오프라인 셋은 정상 질의와 공격 질의를 7:3으로 유지한다.
- Tool 실패 응답도 사용자 친화적으로 표준화한다.
- 인용 없는 답변은 high-confidence라도 차단한다.
트러블슈팅
- 환각 증가: retrieval top-k 조정 + cross-encoder rerank 도입.
- tool loop: max tool depth 제한, 중복 호출 차단.
- 정책 우회: 시스템 프롬프트 의존 대신 실행 전 policy gate 추가.
체크리스트
- tool allowlist/스키마 검증
- RAG 3단계 평가 지표
- red-team 자동화
- citation 미제공 차단
- 운영 차단 로그 감사
결론
좋은 챗봇은 답을 잘하는 시스템이 아니라, 위험한 상황에서 멈출 수 있는 시스템이다.