고위험 AI 에이전트를 위한 평가

메타데이터

• URL: https://www.youtube.com/watch?v=obfPzbapMIM
• 작성일: 2026-10-19
• 채널: AI Engineer (@aiDotEngineer)
• 원본 업로드일: 2026-10-18
• 길이: 53분 32초
• 원제: Evals for High-Stakes AI Agents — Doneyli De Jesus & Annabell Schäfer, Langfuse
• 자막 언어: 영어(English Original, 자동 생성 자막)

📌 핵심 질문 / 고위험 에이전트가 실제로 안전하고 정확하게 일하는지 어떻게 증명할까?

==에이전트의 신뢰성은 응답이 그럴듯한지가 아니라, 실제 실행 흔적·대표 데이터셋·사람의 도메인 판단·재현 가능한 평가를 연결해 입증해야 한다.== 운영 중인 트레이스를 지속적으로 데이터셋으로 환류하고, 결정론적 검사와 LLM 평가자를 함께 사용하며, 프롬프트나 모델이 바뀔 때마다 배포 게이트를 돌리는 것이 핵심이다.

• 일반적인 시스템 지표가 초록색이어도 에이전트가 도구를 실행하지 않고 실행했다고 거짓말할 수 있다.
• 금융처럼 규제가 강한 환경은 민감정보 마스킹, 금지 행동을 포함한 골든 데이터셋, 실패 유형별 평가 기준이 필요하다.
• 자동화는 계측·오류 탐색·실험 실행을 맡기되, 데이터의 대표성·정답 기준·위험 한계는 도메인 전문가가 결정해야 한다.

이 접근을 Langfuse는 트레이싱 → 모니터링 → 데이터셋 구축 → 실험 → 평가 → 운영 데이터 환류로 이어지는 AI 엔지니어링 루프로 설명한다. 일회성 검증이 아니라, 운영에서 발견한 실패를 검증 가능한 사례로 바꾸고 다음 변경의 배포 근거로 되돌리는 반복 체계다.

1. AI 에이전트 평가가 어려운 이유와 반복 개선 루프

1.1. 전통적인 관측 가능성만으로는 사용자 피해를 알아채기 어렵다

1. 정상 지표 뒤에 숨는 행동 실패
   • 환불을 요청한 고객에게 지원 에이전트가 정책을 조회한 뒤 “환불을 처리했다”고 답하지만, 환불 도구는 한 번도 호출하지 않는 사례가 제시된다.
   • 지연 시간이나 오류율은 정상이고 상태판도 초록색일 수 있다. 고객이 몇 주 뒤 환불이 안 됐다고 다시 연락할 때까지 문제를 모를 수 있다.
2. 비결정적 시스템에는 실행 증거가 필요하다
   • 자연스러운 답변은 실제 행동의 증거가 아니다. 어떤 도구를 호출했는지, 무엇을 입력했고 어떤 결과를 받았는지까지 확인해야 한다.
   • 놓친 문제를 운영에서 찾아 재발을 막으려면 에이전트의 모든 단계를 사람이 조사할 수 있는 트레이스와 오류 신호가 있어야 한다.

1.2. 트레이스에서 평가까지 이어지는 AI 엔지니어링 루프

1. 트레이싱과 모니터링은 각각 상세 기록과 대규모 탐색을 맡는다
   • 트레이스는 루트 실행의 총 시간·비용과 각 LLM 생성·도구 호출을 계층적으로 남긴다. 입력·출력·메타데이터까지 보이면 사람과 코딩 에이전트가 실행 경로를 조사할 수 있다.
   • 모니터링은 비용·지연 시간뿐 아니라 준수 여부, 실패 유형, 사용자의 불만 신호(예: 대문자 항의 메시지)를 집계해 사람이 깊이 조사할 대상을 좁힌다.
2. 데이터셋과 실험은 운영 사례를 재현 가능한 비교로 바꾼다
   • 데이터셋은 에이전트가 처리해야 할 대표 입력과 기대 결과·행동·포함 키워드를 묶는다. 범위 밖 요청도 포함해 잘못된 조언을 하지 않고 적절히 이관·거절하는지 확인한다.
   • 실험에서는 프롬프트, 모델, 컨텍스트, 도구 설명 가운데 가급적 한 요소만 바꿔 비교한다. 여러 변수를 동시에 바꾸면 결과가 개선되거나 악화된 원인을 해석하기 어렵다.
3. 평가 결과를 다시 운영과 데이터셋으로 환류한다
   • LLM-as-a-judge는 다른 모델로 출력의 품질을 평가하고, 코드 평가자는 분류·정확 일치·금칙어처럼 명확한 조건을 결정론적으로 확인한다.
   • 루프는 한 번의 출시 체크가 아니다. 프로덕션 트레이스에서 새 실패 사례를 골라 데이터셋에 넣고, 다음 실험과 배포 게이트에서 같은 문제가 재발하는지 반복 측정한다.

1.3. 위험 수준에 따라 시작점과 데이터 수집 방식이 달라진다

1. 낮은 위험의 내부 도구는 관측부터 점진적으로 보강할 수 있다
   • 내부 챗 에이전트라면 먼저 트레이싱과 사용자 불만 모니터링을 시작하고, 실제 사례가 쌓이는 대로 평가 데이터셋을 추가할 수 있다.
   • 반면 고객 대상이거나 규제 산업이라면 프로덕션에서 금지 행동이 일어나는 것을 감수하기 어렵기 때문에 출시 전부터 추적과 평가 근거를 마련해야 한다.
2. 규제 환경의 골든 데이터는 전문가와 운영 프로세스에서 만든다
   • 도메인 전문가가 기대 동작을 직접 큐레이션하거나, 기존 수작업 프로세스를 유지한 채 섀도 런(shadow run)으로 에이전트의 가상 결과를 비교해 정확도와 기준 데이터를 쌓는다.
   • 완전한 인간 개입(human-in-the-loop)으로 시작해 자신 있는 업무만 자동화하고, 불확실하거나 위험한 영역은 사람에게 남기는 방식도 가능하다. 자동 개선은 검증된 골든 데이터셋을 대신할 수 없다.

1.4. Langfuse의 배경과 규모

1. AI 애플리케이션에는 기존 단위 테스트와 다른 검증 층이 필요하다
   • 창업자들은 약 3년 전 Y Combinator 시기에 AI 애플리케이션을 위한 단위 테스트가 마땅치 않다는 문제를 보고 Langfuse를 만들었다.
   • Langfuse는 오픈소스 관측·평가 플랫폼으로 출발해, 개발자와 도메인 전문가, 그리고 최근에는 애플리케이션을 고치는 코딩 에이전트가 함께 쓰는 도구로 넓어졌다.
2. 대규모 도입은 에이전트 관측 데이터의 증가를 보여준다
   • 발표 시점 기준 전 세계 개발자 15만 명 이상이 사용하고, Fortune 50 기업 중 21곳이 핵심 기술 스택에 포함했다고 소개한다.
   • Langfuse 인스턴스에는 매달 900억 건 이상의 관측 데이터가 들어오며, 에이전트가 더 많은 단계를 맡으면서 증가하는 추세라고 설명한다. Ramp, Canva, Khan Academy 등이 사례로 언급된다.

2. 금융기관 고객 지원 에이전트: 트레이스, 개인정보, 안전장치

2.1. 페르소나와 개인정보 보호를 실행 단계에 내장한다

1. 고객 유형별로 안전장치가 유지되는지 본다
   • 시연용 은행 도우미는 소액 예금자부터 초고액 자산가까지 다른 고객 페르소나를 가장한다.
   • 금융기관은 고객 유형이나 질문에 따라 달라지는 가드레일이 실제로 지켜지는지 확인해야 한다. 잘못된 금융 정보에는 법적·재무적·평판상 책임이 뒤따른다.
2. PII는 관측 시스템에 저장되기 전에 가린다
   • 고객이 카드 분실을 문의하면서 카드 번호를 평문으로 입력하는 상황을 만든다. 입력 자체를 통제할 수는 없어도 계측 단계에서 개인정보를 찾아 처리할 수 있어야 한다.
   • 카드 번호나 사회보장번호 같은 개인정보는 Langfuse에 영구 저장되기 전에 마스킹한다. 민감정보의 원본은 금융기관의 시스템 오브 레코드에 두고 관측 도구에 평문으로 남기지 않는 방식이다.

2.2. 도구 실행, 지식 출처, 위험 의도를 하나의 트레이스에서 확인한다

1. 일반 문의도 내부 경로를 남겨야 한다
   • “국제 송금 수수료가 얼마인가?”라는 지식베이스 질문에서 도우미는 답변에 사용한 도구와 데이터 출처를 호출한다.
   • 트레이스는 고객에게 보여줄 답변만이 아니라 LLM 호출, 제공된 도구 목록, 실제 도구 호출, 계정 조회 결과 등 내부 실행 트리를 드러낸다.
2. 금융 조언처럼 위험한 요청은 거절·이관 여부를 평가한다
   • “저축액을 비트코인에 넣어도 될까?”라는 질문은 투자 조언 의도로 분류되어야 한다. 은행 도우미는 직접 권고하지 않고 상담사 등 적절한 경로를 안내해야 한다.
   • 입력 가드레일과 점수는 투자 조언이라는 위험 의도 및 차단 여부를 남긴다. 점수로 필터링하면 비슷한 요청의 실제 사례를 모아 검토할 수 있다.
3. 같은 프레임워크를 음성 상호작용에도 적용한다
   • 고객센터 전화는 음성-텍스트 변환(STT)을 거쳐 평가되며, 카드 차단 요청의 전사문과 에이전트 응답을 트레이스에서 확인한다.
   • 원본 통화 미디어에 연결되는 참조와 텍스트 전사 결과를 함께 보면, 채팅 이외의 접점에서도 가드레일 위반과 응답 품질을 분석할 수 있다.

3. 신뢰할 데이터셋, 사람의 오류 분석, 균형 잡힌 평가자

3.1. 기대 출력은 정답 문장뿐 아니라 의도와 행동도 정의한다

1. 데이터셋은 에이전트의 테스트 케이스다
   • 각 항목은 질문과 기대 결과를 담아 LLM 또는 에이전트가 낸 출력의 품질을 측정한다. 전통적인 소프트웨어 개발에서 QA 전에 테스트 케이스를 두는 것과 같은 역할이다.
   • 기대값은 에이전트가 그대로 말해야 할 정답 문장일 필요가 없다. 어떤 의도로 분류해야 하는지, 어떤 행동을 해야 하는지, 특정 조건을 지켜야 하는지도 평가 기준이 될 수 있다.
2. 목적별 데이터셋을 나눠 위험 영역을 집중 검증한다
   • 프롬프트 인젝션과 가드레일 우회 시도를 찾는 레드팀 데이터셋을 별도로 둘 수 있다.
   • 분쟁이 제기됐지만 해결되지 않은 사례처럼 구체적인 업무·기술 요건을 위한 집합도 둔다. 하나의 평균 점수로 서로 다른 품질 차원을 뭉개지 않는다.

3.2. 운영 트레이스를 대표 표본과 전문가 주석으로 바꾼다

1. 기존 자료와 운영 데이터를 양쪽에서 가져온다
   • 이미 스프레드시트에 축적한 시험 사례는 CSV로 올려 테스트 데이터셋으로 구성할 수 있다.
   • 프로덕션 트레이스도 전문가가 좋은 미래 기준 사례라고 판단한 항목을 골라 데이터셋에 추가할 수 있다. 운영 로그 전체를 무비판적으로 정답 데이터로 간주하지 않는다.
2. 오류 분석(error analysis)은 에이전트가 실제로 어떻게 실패하는지 밝힌다
   • 트레이스를 살펴 도구를 빠뜨렸는지, 필요한 단계를 거쳤는지, 원하는 출력을 냈는지를 확인한다. 다만 수천·수십만 건을 사람이 모두 읽는 방식은 규모가 커지면 불가능하다.
   • 업무·위험 조건으로 필터링해 대표 표본(예: 10~20% 또는 특정 분쟁·카드 문의)을 만들고, 도메인 전문가용 주석 큐(annotation queue)에 보낸다.
3. 전문가의 부담을 낮추고 원문 의견에서 실패 유형을 추출한다
   • 전문가는 예/아니요, 참/거짓, 1~10점 같은 간단한 점수와 짧은 코멘트만 남기면 된다. 예시 코멘트는 “인용이 없으니 모든 경우에 포함해야 한다”였다.
   • 100개를 항목당 30초씩 검토하면 약 50분이므로 짧은 집중 검토 시간으로도 표본을 만들 수 있다. 음성 받아쓰기도 활용해 입력 부담을 줄일 수 있다.
   • 주석을 마친 뒤 LLM에 범주를 새로 발명하게 하지 말고, 사람의 가공되지 않은 코멘트에서 반복되는 실패 패턴과 범주를 추출하게 한다. 사람은 전문 판단에 집중하고 모델은 텍스트 패턴 분류를 맡는다.

3.3. 실패 유형을 점수화하고 서로 다른 평가자를 조합한다

1. 주석에서 측정 가능한 품질 차원을 도출한다
   • 예시 범주에는 전문가가 기대한 출처 정확성, 격식 있는 말투, 고객 언어와 답변 언어의 일치, 요청하지 않은 추가 판매의 부재 등이 포함된다.
   • 범주가 정해지면 각 트레이스에 자동 계산 점수를 붙이거나, 온라인 클라이언트가 실시간으로 계산한 점수를 플랫폼에 전달할 수 있다.
2. LLM 평가자와 결정론적 코드 평가자를 섞는다
   • LLM-as-a-judge는 문맥과 의미를 판단하는 데 유용하지만, 같은 입력에도 오판할 가능성이 0이 아니다.
   • 정규식(exact match 포함)이나 코드 기반 검사는 규칙이 명확한 항목에서 같은 입력에 같은 결과를 낸다. LLM 평가와 결정론적 평가를 품질 차원에 맞게 조합하면 한 평가자의 편향·불안정성에 전부 의존하지 않는다.
3. 판정 기준은 데이터셋과 연결되어야 한다
   • 평가 점수와 실패 모드는 트레이스에 붙어 운영 중 사례별로 조회할 수 있어야 한다.
   • 분류형 위험 점수와 수치형 품질 점수를 함께 두면 금지 의도별 사례와 기준 미달 출력을 각각 필터링해 원인을 조사할 수 있다.

4. 프롬프트 변경을 배포 게이트와 업무 대시보드로 연결한다

4.1. 실험은 동일한 테스트 집합에서 변경의 영향을 비교한다

1. 버전이 다른 설정을 데이터셋 위에서 비교한다
   • 현재 시스템 프롬프트·모델·도구 구성을 기준으로 프롬프트나 모델을 바꾸거나 새로운 도구·데이터 접근 권한을 주었을 때 결과가 어떻게 달라지는지 본다.
   • 실험은 데이터셋을 테스트 케이스로 삼아 여러 예제를 같은 조건에서 실행한다. 감으로 좋아 보이는 변경을 바로 운영에 넣는 대신, 변경 전후를 비교할 증거를 남긴다.
2. 프롬프트 버전 변경을 CI/CD 평가 실행으로 자동화한다
   • Langfuse 프롬프트 설정이 바뀌면 GitHub Actions 작업을 시작하도록 연결하는 시연을 보인다. GitHub·GitLab 등 다른 시스템에 프롬프트 버전을 두더라도 변경을 트리거로 사용할 수 있다.
   • 시연에서는 여러 버전 중 v4를 프로덕션으로 승격하자 CI 평가가 자동 실행된다. 실제 설정 변경은 UI뿐 아니라 API나 CLI로도 수행할 수 있다.
3. 점수별 최소 임계값이 배포 판정을 만든다
   • 출처 재현율, 언어 일치, 정확성, 원치 않는 업셀 금지 등의 평가자를 실행하고, 각 점수에 필요한 최솟값을 둘 수 있다.
   • 임계값을 충족하지 못하면 통과하지 못하는 게이트를 두고, 프롬프트 변경이 품질을 떨어뜨리거나 가드레일을 위반하는지 확인한다. 통과 뒤 PR 생성·사람 검토·병합을 어디까지 자동화할지는 조직이 결정한다.
   • 핵심은 자동으로 무조건 병합하는 것이 아니라, 결정의 근거와 변경 이력을 남겨 “그럴듯해 보여서 배포했다”는 판단을 줄이는 데 있다.

4.2. 업무 대시보드는 조사 우선순위를 좁히고 성과를 맥락화한다

1. 비용과 사람의 업무량을 함께 보여준다
   • 시연 대시보드는 최근 7일 동안 사람 상담원에게 넘어가지 않은 상호작용 1,400건과 그 에이전트 비용이 7달러 미만이었다는 예시를 제시한다.
   • 과거 컨택센터 상담원의 시간당 비용을 15~20달러로 비교해 사업상 편익의 방향을 설명한다. 이는 사례 대시보드의 추정치이며 모든 조직에서 동일한 비용 절감이 보장된다는 의미는 아니다.
2. 실패 유형의 추세를 확인하고 해당 트레이스만 좁혀 본다
   • 최근 7일의 상위 실패 유형 예시로 범위 밖 질문, 비격식 말투, 미해결 분쟁을 보여주고 이들이 시간에 따라 늘어나는지 확인한다.
   • 미해결 분쟁 점수로 트레이스를 필터링하고 저장된 보기로 만들어, 모든 기록 대신 고객 분쟁이 해결되지 않았거나 사람에게 이관된 구체 사례를 조사한다.
3. 고객 반응과 안전 위험도 분리해 추적한다
   • 좋아요·싫어요 반응을 점수로 대시보드에 표시한다. 예시에서 싫어요 비율은 18%이며, 그 표본에서 어떤 일이 벌어졌는지 추가 조사 대상으로 삼는다.
   • 최근 7일에 투자 조언 의도가 89건 감지된 사례를 보여준다. 위험 분류 점수로 요청을 필터링하면 에이전트가 부적절한 금융 조언을 하지 않았는지 확인할 수 있다.

5. 코딩 에이전트와 전문가가 맡을 일, 시작을 위한 권고

5.1. 완전 자동화와 완전 수작업 사이에서 품질을 만든다

1. “에이전트 고쳐줘”라는 포괄적 위임은 품질을 보장하지 않는다
   • 코딩 에이전트에 데이터 접근을 연결하고 “다 고쳐라”고 맡기면, 검증 없이 저품질 변경을 대량 생산할 수 있다.
   • 반대로 앱 계측, 실패 탐색, 모든 데이터를 사람이 다시 읽는 일을 전부 수작업으로 유지하는 것도 규모에 맞지 않는다.
2. 자동화와 인간의 취향·도메인 판단을 분리한다
   • 코딩 에이전트는 계측 적용, 실패 유형 탐색, 평가 실행, 여러 후보 실험 같은 반복 작업을 자동화할 수 있다.
   • 사람은 어떤 문제가 중요한지, 데이터가 대표성을 갖는지, 어떤 동작이 정답인지, 어디까지 자동화할지를 정한다. 품질 좋은 결과는 자동화와 전문가 판단이 균형을 이룰 때 나온다.

5.2. 다음 날 시작할 수 있는 순서

1. Langfuse 에이전트 스킬과 기존 근거를 준비한다
   • Langfuse 스킬은 마크다운 지침과 문서·통합·아카데미 자료를 연결해 코딩 에이전트가 계측과 데이터셋, 평가자 작성의 권장 방식을 따르게 돕는다.
   • 과거 데이터, 프로덕션 표본, 도메인 전문가가 만든 사례에서 평가 가능한 기준 집합을 모은다. 자동화가 기준 데이터 자체를 대신하도록 두지 않는다.
2. 규제 산업은 절대 허용할 수 없는 한계를 명시한다
   • 금융 예시에서는 투자 조언을 절대 제공하지 않는 규칙을 하드 리밋으로 정하고 평가 데이터셋에 금지 사례를 넣는다.
   • 금지 행동이 실제로 발생하지 않는 것이 목표지만, 적어도 발생 시 평가에서 검출되도록 기준과 게이트를 만든다.
3. 재사용 가능한 시연 자료와 학습 자료를 활용한다
   • 데모 저장소는 온라인으로 공개되어 있지만 데이터는 고객 자료가 아닌 가상의 예시다. 조직은 필요한 부분을 가져와 자체 업무 사례로 바꿀 수 있다.
   • Langfuse Academy의 AI 엔지니어링 설명과 셀프 서비스 워크숍은 계측부터 평가까지 직접 따라 해보는 자료다. 배포 게이트를 다루는 후속 세션, 부스 9, 얼굴 스티커 생성, 팀·창업자와 함께하는 커뮤니티 러닝도 안내한다.

5.3. Q&A: 저장소 선택과 LLM 평가자 신뢰도

1. ClickHouse 의존성과 AWS 자체 호스팅에 대한 질문
   • Langfuse는 초기에 PostgreSQL을 사용했지만 하루 수십억 건에 이르는 이벤트 규모를 감당하기 어려워 분석 데이터 계층을 ClickHouse로 옮겼다고 답한다.
   • 관리형 클라우드는 AWS에서 운영되며, 고객이 직접 인프라를 관리하려면 자체 호스팅 배포도 가능하다. 데이터를 S3로 내보내거나 API·CLI·MCP로 조회할 수 있다.
2. LLM 평가자가 사람과 일치하는지 검증하는 방법
   • 대표 표본을 사람이 먼저 평가하고, LLM 평가자의 판정이 사람 평가자와 얼마나 일치하는지 비교해 기준 데이터에 맞게 조정한다. 가능하면 복수의 사람 평가자도 활용한다.
   • 운영 데이터에 적용할 때는 표본이 계속 대표성을 유지하는지 확인한다. 초반에는 놓치는 사례를 줄이도록 거짓 양성(false positive)을 다소 더 허용하고, 실제 데이터를 보며 과잉 판정을 점차 낮추는 접근을 권한다.

주요 발언 모음

“AI agents can fail while the system metrics themselves look green.”

“The expected output doesn't necessarily need to be the answer that the agent is going to give.”

“You want to have a mix of both.”

“You're not pushing a PR just running on vibes.”

“Make it very simple for the domain expert.”

핵심 데이터 & 수치

• 150,000명 이상: 발표 시점 기준 Langfuse를 사용하는 전 세계 개발자 수.
• Fortune 50 중 21곳: Langfuse를 핵심 기술 스택에 포함한 기업 수로 소개됨.
• 월 900억 건 이상: Langfuse 인스턴스에 수집되는 관측 데이터 규모.
• 10~20% 표본: 전체 트레이스를 전수 검토하지 않고 전문가 검토 표본을 만드는 예시 비율.
• 100건 × 건당 30초 ≈ 50분: 간단한 점수와 코멘트로 전문가 주석 부담을 설명한 계산.
• 최근 7일, 1,400건, 7달러 미만: 시연 대시보드의 사람 상담원 미이관 건수와 에이전트 비용 예시.
• 시간당 15~20달러: 과거 컨택센터 상담원 인건비와 비교하기 위해 언급한 범위.
• 싫어요 18%, 투자 조언 위험 89건: 같은 시연 대시보드의 추가 조사 신호 예시.
• 하루 수십억 이벤트: PostgreSQL에서 ClickHouse로 데이터 저장 계층을 옮긴 배경으로 언급된 규모.

결론 및 시사점

1. 운영 지표와 자연스러운 답변만으로 에이전트의 성공을 판단하지 말고, 실제 도구 실행과 출력 품질을 트레이스로 확인한다.
2. 고위험 시스템은 민감정보를 저장 전에 마스킹하고, 금지 행동과 경계 사례를 도메인 전문가가 만든 데이터셋에 포함한다.
3. LLM 평가의 확률적 오류를 코드 기반 결정론적 평가와 결합하고, 사람의 대표 표본 평가로 판정 기준을 보정한다.
4. 운영에서 발견한 실패를 데이터셋으로 환류하고, 프롬프트·모델 변경마다 CI 평가와 점수 임계값을 통과하도록 만든다.
5. 반복 계측과 실험은 코딩 에이전트에 맡기되, 문제 정의·대표성·위험 허용 한계는 사람이 책임진다.

20줄 핵심 요약

AI 에이전트는 도구를 호출하지 않고도 성공했다고 답할 수 있어 시스템 상태와 실제 업무 완료를 별도로 검증해야 한다.

환불 도구를 실행하지 않은 지원 에이전트처럼 지연 시간과 오류율이 정상이어도 수 주 뒤에야 드러나는 실패가 생긴다.

트레이싱은 LLM 생성과 도구 호출, 입력·출력, 시간, 비용을 남겨 사람과 코딩 에이전트가 실행 경로를 조사하게 한다.

모니터링은 비용·지연 시간뿐 아니라 규정 준수, 실패 유형, 대문자 항의 같은 불만 신호를 집계해 조사 대상을 좁힌다.

데이터셋은 대표 입력과 기대 답변·의도·행동을 묶으며 범위 밖 요청과 금지 사례도 포함할 수 있다.

실험에서는 프롬프트·모델·컨텍스트·도구 설정 중 한 가지를 바꿔 데이터셋의 같은 사례로 영향 원인을 비교한다.

운영 트레이스를 전문가가 검토해 가치 있는 사례만 골라 데이터셋으로 환류해야 자동 개선이 근거를 갖는다.

저위험 내부 에이전트는 트레이싱과 불만 모니터링부터 시작할 수 있지만 규제·고객 대상 시스템은 사전 평가가 중요하다.

은행 도우미 시연은 고객 페르소나별 가드레일과 카드 번호·사회보장번호의 저장 전 개인정보 마스킹을 보여준다.

국제 송금 수수료 질문은 지식 출처와 도구 호출을 남기고 비트코인 투자 질문은 투자 조언 위험으로 분류해 이관한다.

음성 고객센터도 음성-텍스트 변환과 통화 전사, 응답을 연결해 채팅과 같은 평가 흐름으로 분석할 수 있다.

레드팀 공격이나 미해결 분쟁처럼 목적별 데이터셋을 나누고 정답 문장 외에 의도·행동 기준도 평가한다.

전문가 주석 큐는 대표 표본의 트레이스에 간단한 점수와 코멘트를 붙여 대규모 전수 검토의 부담을 낮춘다.

LLM은 전문가 코멘트에서 반복 실패 유형을 추출하게 하고 전문가는 기준을 정의하는 데 시간을 쓴다.

LLM 평가자는 사람의 대표 표본 판정과 일치하도록 보정하고 정규식·정확 일치 같은 코드 평가와 함께 사용한다.

프롬프트 버전 변경을 GitHub Actions와 연결하면 동일 데이터셋 평가와 출처 재현율·언어 일치·정확성 임계값을 자동 검사한다.

시연 대시보드는 7일간 사람에게 이관되지 않은 1,400건과 7달러 미만 비용, 싫어요 18%, 투자 조언 위험 89건을 예시로 보인다.

분쟁 미해결이나 투자 조언 같은 위험 점수로 트레이스를 필터링하면 수많은 기록 대신 실제 실패 사례를 집중 조사할 수 있다.

포괄적인 “에이전트를 고쳐라” 자동화는 저품질 변경을 낳을 수 있으므로 반복 작업은 자동화하고 문제 정의는 전문가가 맡는다.

규제 환경은 절대 금지할 행동을 데이터셋과 배포 게이트에 명시하고 코딩 에이전트·사람·CI가 함께 개선 루프를 유지한다.