10월 20일 화요일

고위험 에이전트의 변경을 무엇으로 막고, 무엇으로 통과시킬 것인가?

환불 지원 에이전트가 정책을 조회한 뒤 환불을 처리했다고 답하면서 실제 환불 도구는 호출하지 않는다면, 지연 시간과 오류율이 정상이어도 업무는 실패했다. 그래서 평가의 기본 단위는 최종 문장만이 아니라 LLM 생성, 제공된 도구, 실제 호출, 입력과 출력, 비용과 시간을 연결한 실행 트레이스다. 모니터링은 비용과 지연 시간뿐 아니라 준수 여부, 실패 유형, 사용자 불만 신호를 집계해 사람이 자세히 볼 실행을 좁히는 앞단으로 둔다. 운영에서 발견한 실패를 대표 데이터셋으로 돌려보내고, 같은 사례로 프롬프트·모델·컨텍스트·도구 변경을 비교한 뒤, 점수 임계값을 CI 배포 게이트에 연결해야 일회성 데모가 반복 가능한 품질 근거가 된다.

1. 01

   트레이스는 행동 증거여야 한다

   고객에게 보낸 답변만 저장해서는 도구 누락을 판별할 수 없다. 루트 실행 아래에 모델 호출과 도구 호출을 계층적으로 남기고, 어떤 입력과 결과가 오갔는지 조사할 수 있어야 한다. 금융 시연은 지식 출처와 계정 조회 경로, 투자 조언 의도와 거절·이관 여부를 같은 흐름에서 확인했다. 카드 번호나 사회보장번호 같은 개인정보는 관측 저장소에 영구 기록되기 전에 마스킹하고 원본은 시스템 오브 레코드에 남긴다.

2. 02

   운영 로그 전체가 정답 데이터는 아니다

   기존 시험 사례와 프로덕션 트레이스를 함께 쓰되, 도메인 전문가가 미래 기준 사례로 적합한 표본을 골라야 한다. 전체의 10~20%나 특정 분쟁·카드 문의처럼 위험 조건으로 좁힌 주석 큐에서 전문가는 간단한 점수와 짧은 코멘트를 남긴다. 모델은 그 의견에서 반복 실패 유형을 추출할 수 있지만, 어떤 문제가 중요한지와 어떤 행동이 정답인지는 사람이 결정한다. 운영 기록을 무비판적으로 골든 데이터로 승격하면 기존 오류도 기준으로 굳어진다.

3. 03

   확률적 판정과 결정론적 검사를 분업한다

   문맥·말투·출처 적합성처럼 의미 판단이 필요한 항목에는 LLM 평가자가 유용하지만 같은 입력에도 오판할 수 있다. 금칙어, 정확 일치, 명시적 분류 조건처럼 규칙이 분명한 항목은 정규식과 코드 검사로 고정한다. LLM 판정은 사람이 먼저 평가한 대표 표본과 얼마나 일치하는지 보정하고, 초반에는 놓치는 사례를 줄이기 위해 거짓 양성을 다소 허용한 뒤 실제 운영 데이터를 보며 과잉 판정을 낮춘다. 한 평가자의 평균 점수로 서로 다른 위험을 뭉개지 않는 것이 핵심이다.

4. 04

   변경 하나마다 같은 시험 집합을 다시 건넌다

   실험은 프롬프트, 모델, 컨텍스트, 도구 설명 가운데 가능하면 한 요소만 바꾸고 동일 데이터셋에서 전후 차이를 측정한다. 시연에서는 프롬프트 버전 승격이 GitHub Actions 평가를 시작하고, 출처 재현율·언어 일치·정확성·원치 않는 추가 판매 금지 같은 점수별 최솟값을 검사했다. 통과 뒤 PR 생성과 사람 검토, 병합을 어디까지 자동화할지는 별도 운영 결정이다. 게이트의 목적은 자동 병합이 아니라 변경 근거와 실패 이력을 남기는 데 있다.

낮은 위험의 내부 도구는 트레이싱과 불만 모니터링부터 시작해 실제 실패를 데이터셋으로 축적할 수 있다. 반면 고객 대상이나 규제 환경은 투자 조언 금지처럼 허용할 수 없는 행동을 출시 전에 명시하고, 섀도 런이나 사람 개입으로 기준 데이터를 마련해야 한다. 반복 계측과 실험 실행은 자동화할 수 있지만 대표성, 정답, 위험 허용 한계의 소유권까지 에이전트에 넘길 수는 없다. 프로덕션 평가는 관측, 표본화, 사람 판정, 자동 평가, 배포 게이트가 다시 운영 데이터로 이어지는 폐쇄 루프여야 한다.