6.8 AI 평가와 테스트

개요와 동기

일반 소프트웨어를 테스트하는 일은 마음 놓이는 가정에 기댑니다. 같은 입력이 주어지면 프로그램은 같은 출력을 돌려주고, 그 출력이 무엇이어야 하는지 정확히 단언할 수 있다는 것입니다. 인공지능은 그 가정을 깹니다. 모델은 같은 질문에 두 가지 다른 방식으로 답할 수 있고, 둘 다 받아들일 만할 수 있습니다. 통과 또는 실패가 아니라 틀림에서 훌륭함까지의 스펙트럼으로 채점될 수 있습니다. 그리고 단언할 단 하나의 정답이 없는 경우가 많습니다. 그래서 평가의 규율, 곧 하나의 출력을 하나의 기대값에 대조하는 대신 많은 대표적 사례에 걸쳐 모델이 얼마나 잘 행동하는지 측정하는 일이 신뢰할 수 있는 모든 AI 시스템의 뼈대가 됩니다. 팀이 자신들을 난처하게 만드는 AI 기능을 출하할 때, 근본 원인은 거의 항상 출시 전에 품질을 측정할 진지한 방법이 없었다는 것입니다.

큰 팀에게 평가는 변경을 안전하게 만드는 것입니다. 모델을 바꾸고, 프롬프트를 다시 쓰고, 검색을 튜닝하고, 도구를 더할 것이며, 그 변경 하나하나가 탄탄하다고 생각했던 행동을 조용히 저하시킬 수 있습니다. 품질을 측정하는 반복 가능한 방법이 없으면 모든 변경은 도박이고 모든 회귀는 사용자가 발견합니다. 이 장은 구축하는 장들, 곧 생성형 AI와 LLM 애플리케이션(6.3장), AI 에이전트와 에이전트 시스템(6.7장), 머신러닝 엔지니어링과 MLOps(6.2장)의 측정 짝입니다. 일반적인 테스트 전략(2.4장)을 확률적 세계로 확장합니다.

기업과 정부 환경은 판돈을 더 높입니다. 수십 개의 AI 기능을 운영하는 기업은 모든 팀이 처음부터 채점을 다시 발명하지 않도록 공유 평가 플랫폼이 필요합니다. 정부 기관은 문서화되고 감사 가능한 평가가 필요합니다. “테스트했습니다”가 “여기 증거, 데이터셋, 지표, 승인이 있습니다”가 되어야 하기 때문입니다. 평가는 책임 있고 신뢰할 수 있는 AI(6.5장)가 가치 선언을 멈추고 규제 기관에 보일 수 있는 무엇이 되는 곳입니다.

핵심 원칙

평가를 출시 직전에 덧붙이는 사후 고려가 아니라 일급 제품으로 다루십시오.
모델을 돋보이게 하는 장난감 예시가 아니라 실제 사용을 반영하는 대표적 데이터로 측정하십시오.
빠른 반복을 위한 오프라인 평가와 실측값을 위한 온라인 평가를 결합하십시오.
사람의 판단을 닻으로 삼고, 모든 자동 채점기를 그에 대해 보정하십시오.
평가 세트를 오염으로부터 지키십시오. 그러지 않으면 숫자가 여러분에게 거짓말을 합니다.
품질이 조용히 회귀할 수 없도록 평가를 지속적 통합에 관문으로 연결하십시오.
프로덕션에서 계속 측정하십시오. 코드가 바뀌지 않아도 품질은 드리프트합니다.

권장 사항

평가 주도 개발을 채택한다

프롬프트를 튜닝하거나 모델을 고르기 전에 평가를 쓰십시오. 이는 테스트 주도 개발을 반영합니다. “좋음”이 무엇을 뜻하는지 측정 가능한 용어로 정의한 뒤 그것을 향해 만듭니다. 여기서 평가란 각 출력에 숫자나 등급을 돌려주는 채점 방법과 짝지어진 입력의 데이터셋을 뜻합니다. 작게 시작하십시오. 실제 사용자 의도를 반영하는 신중하게 고른 스무 개의 사례가 무작위 천 개를 이깁니다. 시스템이 실패하는 곳을 배워 가며 세트를 키우고, 같은 실수가 눈에 띄지 않고 돌아오지 못하도록 모든 프로덕션 실패를 영구 사례로 되돌려 넣으십시오.

평가 주도 개발은 팀의 행동을 바꿉니다. 좋음의 정의가 적혀 있고 실행 가능하면, 변경이 도움이 되었는지에 대한 논쟁이 취향의 문제가 아니라 확인 가능한 것이 됩니다. 평가 세트를 그것이 측정하는 프롬프트와 코드 바로 옆, 버전 관리에 있는 리뷰된 산출물로 만드십시오.

오프라인과 온라인 평가를 분리하고 둘 다 쓴다

오프라인 평가는 고정된 데이터셋을 통제된 환경에서 시스템에 통과시킵니다. 빠르고, 싸고, 반복 가능해서 아무것도 출하되기 전에 버전을 비교할 수 있습니다. 온라인 평가는 과업 완료, 에스컬레이션 비율, 엄지 위/아래 피드백, 하류의 비즈니스 성과 같은 지표로 실제 사용자와 함께 라이브 시스템을 측정합니다. 오프라인은 변경이 안전할 가능성이 큰지 알려 주고, 온라인은 그것이 실제로 효과가 있었는지 알려 줍니다. 오프라인 세트는 현실을 온전히 포착하지 못하고 온라인 신호는 유일한 가드레일이 되기에는 너무 늦게 도착하므로 둘 다 필요합니다.

둘을 루프로 잇습니다. 온라인 지표가 떨어지거나 사용자가 나쁜 답을 표시하면 그 사례를 포착하고, 레이블을 붙이고, 오프라인 세트에 접어 넣으십시오. 실험은 모든 제품 변경에 쓰는 것과 같은 통제된 비교, 곧 제품 분석과 실험(7.4장)의 영역을 거치게 하십시오. 새 모델이 과업 성공을 끌어올림을 보이는 A/B 테스트는 어떤 오프라인 점수보다 가치가 있지만, 테스트를 감히 돌릴 수 있게 한 것은 오프라인 점수입니다.

대표적 평가 세트를 만들고 오염에 대비한다

평가는 데이터만큼만 정직합니다. 사용자가 실제로 묻는 것의 분포를 반영하는, 검증된 기대 출력이나 채점 루브릭이 있는 입력의 선별된 컬렉션인 골든 데이터셋을 만드십시오. 흔한 사례, 드물지만 결정적인 사례, 적대적 사례, 시스템이 현재 틀리는 사례입니다. 괜찮은 평균 안에 실패하는 범주를 숨기지 않고 세그먼트별로 품질을 읽을 수 있도록 층화하십시오. 틀린 답 위에 세운 골든 세트는 없는 것보다 나쁘므로 도메인 전문가가 기대 답을 검증하게 하십시오.

그다음 그 데이터를 오염으로부터 보호하십시오. 테스트 세트 오염은 평가 예시가 모델의 학습 데이터나 프롬프트 자체로 새어 들어가, 모델이 사실상 답을 본 탓에 잘 수행하는 것처럼 보일 때 일어납니다. 모델이 공개 벤치마크에서 훌륭한 점수를 내고 실제 트래픽에서 비틀거릴 수 있는 이유입니다. 평가 데이터의 일부를 비공개로 유지하고 신뢰할 수 없는 제3자에게 절대 보내지 마십시오. 세트를 시간이 지남에 따라 갱신하십시오. 개발자가 점수가 무의미해질 때까지 평가 세트에 대해 프롬프트를 손으로 튜닝하는, 진짜 개선이 아니라 테스트에 대한 과적합의 형태인 더 미묘한 누출을 경계하십시오. 가끔만 보는 새 보류 세트를 두십시오.

과업에 맞는 지표를 고른다

측정을 출력의 모양에 맞추십시오. 올바른 레이블이 있는 분류와 추출에는 고전적 지표가 적용됩니다. 정밀도와 재현율(표시한 항목 중 몇 개가 맞았는지, 맞는 항목 중 몇 개를 찾았는지), 그 둘의 균형을 맞추는 F 점수, 정확 일치 정확도입니다. 확신 있는 확률이 중요한 모든 곳에서는 보정, 곧 진술된 80퍼센트 확신이 약 80퍼센트의 시간 동안 맞는지를 측정하십시오. 언제 확신이 없는지 아는 잘 보정된 모델이 과신하는 모델보다 훨씬 안전하기 때문입니다.

생성형 출력은 더 어렵습니다. 원래 기계 번역과 요약을 위해 만들어진 BLEU와 ROUGE 같은 참조 기반 지표는 겹치는 단어와 구를 세어 생성된 텍스트를 참조 텍스트와 비교합니다. 싸고 반복 가능하지만 품질의 약한 대리입니다. 표면의 겹침에 보상하고 참조와 다르게 표현된 올바른 답을 벌합니다. 이를 좋음의 정의가 아니라 거친 회귀 신호로 쓰십시오. 개방형 과업에는 루브릭 기반 채점이 더 낫습니다. 명시적 기준(근거가 있는가, 완전한가, 안전한가, 올바르게 형식화되었는가)을 정의하고 각각을 채점하십시오. 루브릭은 주관적 품질을 읽을 수 있고 리뷰할 수 있게 만듭니다.

LLM 심사자를 쓰되, 사람에 대해 보정한다

생성형 출력을 손으로 채점하는 것은 확장되지 않으므로, 팀들은 점점 강한 대규모 언어 모델을 자동 심사자로 쓰며, 입력, 출력, 루브릭으로 프롬프트하고 점수를 매기게 합니다. 이 LLM 심사자 접근은 빠르고 놀랍도록 유능하지만, 관리해야 할 실제 편향을 지닙니다. 심사자는 더 긴 답을 선호하고, 쌍별 비교에서 처음 보인 옵션을 선호하고(위치 편향), 자기 글쓰기 스타일에 보상하며, 유창하지만 틀린 추론에 흔들릴 수 있습니다. 점검하지 않으면 편향된 심사자는 확신에 차고 정밀하지만 틀린 숫자를 줍니다.

심사자를 사람 레이블에 대해 보정하십시오. 사람들이 표본을 채점하게 한 뒤 모델 심사자가 그들과 얼마나 잘 일치하는지 확인하고, 신뢰할 만큼 일치가 높아질 때까지 심사자 프롬프트를 계속 튜닝하십시오. 알려진 편향을 의도적으로 줄이십시오. 옵션 순서를 무작위로 하고, 길이를 통제하고, 맨숫자 대신 이유가 붙은 루브릭에 닻을 둔 점수를 요청하십시오. 심사자를 고정된 신탁이 아니라 주기적 재보정이 필요한 측정 기기로 다루십시오. 심사자를 만들 때는 약한 심사자가 약한 자이므로 사용 가능한 가장 유능한 모델을 기본으로 하십시오.

실측값을 위해 사람을 루프에 둔다

사람의 평가는 모든 자동 지표가 견주어 측정되는 닻으로 남아 있으므로 잘 하는 데 투자하십시오. 분명한 주석 지침을 쓰고, 주석자를 교육하고, 독립적인 리뷰어가 같은 사례에 같은 등급을 주는 정도인 주석자 간 일치도를 측정하십시오. 낮은 일치도는 보통 리뷰어가 부주의해서가 아니라 루브릭이 모호하다는 뜻이므로 루브릭을 고치십시오. 고위험 영역에서는 법률이나 의료 답을 판단할 맥락이 없는 크라우드 워커가 아니라 자격 있는 전문가를 쓰십시오.

안전과 적대적 견고성을 위해 레드팀한다

표준 평가 세트는 합리적인 입력에서 시스템이 옳은 일을 하는지 측정합니다. 자신의 시스템을 의도적으로 공격해 어디서 잘못 행동하는지 찾는 레드팀은 압박 아래서 무슨 일이 일어나는지 측정합니다. 프롬프트 인젝션, 탈옥, 안전하지 않은 콘텐츠, 프라이버시 유출, 편향된 출력을 찔러 보십시오. 일회성 연습이 아니라 반복 가능한 스위트로 만드십시오. 성공한 모든 공격을 영구 회귀 사례로 바꿔 고친 취약점이 고쳐진 채로 남게 하십시오. 이 작업은 책임 있고 신뢰할 수 있는 AI(6.5장)에 직접 연결되며, 규제 환경에서는 안전 리뷰를 충족하는 증거인 경우가 많습니다.

에이전트를 끝에서 끝까지의 과업 성공으로 평가한다

여러 단계에 걸쳐 계획하고 행동하는 에이전트는 한 번에 하나의 출력으로 판단할 수 없습니다. 중요한 것은 과업 전체가 성공했는가입니다. 에이전트가 회의를 잡았는가, 티켓을 해결했는가, 워크플로를 올바르고 안전하게 완료했는가. 에이전트가 현실적이지만 안전한 픽스처에 대해 행동할 수 있는 샌드박스 환경에서 과업 수준 평가를 만들고, 최종 결과와 궤적, 곧 거기에 이르기 위해 취한 단계와 도구 호출의 순서를 함께 채점하십시오. 위험하거나 낭비적인 경로로 도달한 올바른 답도 여전히 문제입니다. 이는 단 하나의 잘못된 행동이 실제 결과를 낳을 수 있는 AI 에이전트와 에이전트 시스템(6.7장)에 필수입니다.

평가를 CI에 연결하고 프로덕션을 모니터링한다

평가를 자동화하십시오. 모든 프롬프트, 모델, 검색 변경마다 지속적 통합(CI)에서 오프라인 스위트를 돌리고, 단위 테스트로 관문 통제하듯 그것으로 머지를 관문 통제하십시오. 이는 더 넓은 테스트 전략(2.4장)에 뿌리를 둔 실천입니다. 점수가 잡음이 있으므로 완벽한 실행을 요구하는 대신 임계값과 추세로 관문 통제하고, 핵심 지표가 하한 아래로 떨어지거나 정해진 폭 넘게 회귀하면 빌드를 실패시키십시오. 그다음 프로덕션에서 계속 지켜보십시오. 오프라인 테스트가 놓치는 느린 저하를 잡도록 품질 신호, 출력 분포, 입력 드리프트를 모니터링하십시오. 이는 머신러닝 엔지니어링과 MLOps(6.2장)의 관측 가능성 실천과 연결됩니다. 출시 때 정확했던 모델도 그것이 기술하는 세상이 밑에서 바뀌면 쇠퇴할 수 있습니다.

장단점

평가 접근	장점	단점	가장 적합한 때
사람 평가	최고의 충실도. 뉘앙스를 포착	느리고 비싸며 확장하기 어려움	실측값, 고위험, 심사자 보정
LLM 심사자	빠르고 싸며 큰 세트로 확장	편향됨. 보정 필요	생성형 출력의 빈번한 오프라인 실행
참조 기반 지표 (BLEU, ROUGE)	싸고, 결정적이고, 반복 가능	실제 품질의 약한 대리	거친 회귀 신호. 최종 판정은 아님
고전적 지표 (정밀도, 재현율, F 점수)	객관적이고 잘 이해됨	올바른 레이블이 있는 과업에만 맞음	분류, 추출, 검색
공개 벤치마크	모델 간 비교 가능. 설정 없음	오염. 과업에 대한 낮은 적합	초기 모델 후보 추리기. 릴리스 관문은 아님
온라인 평가 (A/B, 피드백)	실제 사용자와 성과를 반영	느림. 노출 뒤에 도착	변경이 실제로 도움이 되었는지 확인

핵심 긴장은 속도 대 충실도입니다. 사람 평가는 가장 신뢰할 만하지만 가장 덜 확장되고, 자동 채점은 그 반대입니다. 해결은 층을 쌓는 것입니다. 지속적 반복에는 빠르고 싼 방법을 쓰고, 정기적 보정으로 그 방법을 사람의 판단에 닻을 내리고, 완전한 사람 리뷰는 가장 판돈이 큰 결정과 싼 지표가 여전히 현실을 따라가는지 확인하는 데 남겨 두십시오. 두 번째 긴장은 오프라인의 편의 대 온라인의 진실입니다. 오프라인 세트는 빨리 움직이게 해 주지만 프로덕션을 온전히 비추지 못하므로, 강한 오프라인 점수를 끝났다는 증명이 아니라 신중한 온라인 테스트를 돌려도 된다는 허가로 다루십시오.

팀과 논의할 질문

“충분히 좋음”의 기준은 무엇이며, 그것을 정의하는 평가 세트는 누가 소유합니까? 모든 AI 기능에는 암묵적 품질 임계값이 있고, 그것이 암묵적으로 남으면 각 엔지니어가 느낌으로 자기 것을 정하며 논쟁은 방에서 가장 연차가 높은 사람이 정리합니다. 기준을 세그먼트별 목표 점수가 있는 실행 가능한 평가 세트로 적으면 그 논쟁이 측정 가능한 질문이 됩니다. 현재의 성공 정의, 그 뒤의 데이터, 실제로 누가 유지하는지에 대한 정직한 설명을 가져오십시오. 주인 없는 평가 세트는 돌보지 않는 다른 코드만큼 빨리 썩기 때문입니다. 기준이 위험 등급에 따라 다른지 결정하십시오. 공개 대면 법률 답은 내부 브레인스토밍 보조 도구보다 높은 기준을 넘어야 합니다. 답은 현재 누군가 측정이 자신과 사용자 사이에 서 있지 않은 채 AI 변경을 출하할 수 있는지 알려 주어야 합니다.
평가 숫자가 오염되거나 과적합된 것이 아니라 정직하다는 것을 어떻게 압니까? 점수는 실제 품질을 예측할 때만 유용하며, 그러기를 멈추는 방법은 많습니다. 벤치마크 데이터가 학습으로 새어 들어가거나, 개발자가 숫자가 무의미해질 때까지 테스트 세트에 대해 프롬프트를 튜닝하거나, 검증된 적 없는 답 위에 골든 데이터셋을 세우는 것입니다. 평가 데이터가 어디서 왔는지, 얼마나 비공개로 유지되는지, 얼마나 자주 갱신되는지의 증거를 가져오십시오. 드물게 보는 새 보류 세트를 유지해, 적어도 아무도 그에 대해 최적화하지 않은 숫자 하나는 있게 하는지 논의하십시오. 모델이 영향을 준 적 없는 데이터에서도 점수가 왜 유지될지 설명할 수 없다면, 자신의 반영을 측정하고 있는 것입니다.
사람은 어디서 루프에 남으며, 자동 심사자를 그들에게 어떻게 보정된 채로 유지합니까? LLM 심사자와 참조 지표는 규모에서 채점하게 해 주는데, 확인하지 않으면 보이지 않는 방식으로 사람의 판단에서 벗어납니다. 자동 채점과 사람 리뷰 사이의 현재 일치율, 얼마나 최근에 측정했는지, 어떤 편향(길이, 위치, 스타일)을 테스트했는지 가져오십시오. 비용과 무관하게 사람 채점자가 필요한 결정, 대개 가장 판돈이 크고 자동 심사자를 재보정하는 데 쓰이는 결정을 정하십시오. 주석의 품질도 이야기하십시오. 일관성 없는 사람 레이블에 대해 보정된 심사자는 그 일관성 없음을 물려받기 때문입니다. 답은 일회성 축복이 아니라 재보정 일정을 내놓아야 합니다.
오늘 어떤 AI 변경이 평가로 관문 통제되며, 어떤 것이 여전히 누군가의 확신만으로 사용자에게 닿습니까? 일부 변경에는 돌고 다른 변경에는 돌지 않는 관문은 안전의 환상을 주면서 진짜 회귀가 관문 없는 경로로 빠져나가게 둡니다. 조용한 프롬프트 수정, 검색 튜닝, 아무도 변경으로 치지 않은 모델 버전 상향입니다. 큰 팀에서는 프롬프트를 건드릴 수 있는 사람의 수가 늘수록 위험이 커집니다. 관문 없는 경로마다 어떤 데이터셋도 보지 못한 회귀를 출하할 방법이 되기 때문입니다. 현재 지속적 통합에서 오프라인 스위트를 촉발하는 변경 유형의 목록, 촉발하지 않는 것, 관문 없는 변경으로 추적된 최근 몇 건의 사고를 가져오십시오. 잡음이 있는 점수는 완벽한 실행을 요구하는 대신 하한과 회귀 폭을 요구하므로, 관문이 어떤 임계값과 추세를 시행하는지 정하십시오. 기업과 정부 환경에서는 변경이 측정되었다는 증거가 누군가 한 번 찍은 스크린샷이 아니라 감사 추적의 일부가 되도록, 관문을 릴리스 기록 자체에 묶으십시오.
평가에 얼마를 쓰고 있으며, 그 지출이 각 기능의 위험에 맞춰져 있습니까? 평가는 공짜가 아닙니다. 주석 노동, 자동 심사자가 매 실행마다 태우는 컴퓨트, 골든 데이터셋을 대표적으로 유지하는 상시 작업은 모두 실제 돈이 들고, 이 비용의 이름을 대지 않는 팀은 고위험 기능에 과소 투자하거나 일회용 기능을 도금하는 경향이 있습니다. 경쟁하는 끌림은 충실도 대 예산 사이에 있습니다. 가장 신뢰할 만한 방법인 전문가의 사람 리뷰는 가장 덜 확장되므로 어디서나 감당할 수 없고 어디서 값을 하는지 정해야 합니다. 평가 실행당 현재 비용, 기능당 주석 시간, 각 시스템의 정직한 위험 등급을 가져와, 방이 돈이 가는 곳과 위험이 사는 곳을 대조해 볼 수 있게 하십시오. 기업에게 이것은 많은 팀에 걸쳐 주석과 컴퓨트를 분할 상환하는 공유 평가 플랫폼의 가장 강한 논거이고, 정부 기관에게 위험 등급은 감독 기관이 나중에 요구할 증거의 깊이에 직접 대응해야 합니다.
더 나은 모델이 나오면 도움이 되는지 얼마나 빨리 입증할 수 있으며, 누가 전환할 수 있습니까? 평가 스위트의 가치는 더 강한 모델이 출시되는 날 가장 날카롭게 실현됩니다. 골든 데이터셋과 레드팀 스위트를 한나절에 새 모델에 돌릴 수 있는 팀은 손으로 채점하는 팀이 몇 달 놓칠 개선을 채택할 수 있기 때문입니다. 긴장은 속도와 신중함 사이에 있습니다. 더 나은 모델이 나타나는 날 움직이고 싶지만, 교체가 평균 점수가 가리는 답의 범주를 조용히 저하시키게 둘 수는 없습니다. 새 제공자에 대한 전체 오프라인 비교를 돌리는 데 현재 걸리는 시간, 평가 세트가 모델 간에 이식 가능한지, 회귀가 가장 중요한 세그먼트를 가져오십시오. 규제 및 공공 환경에서는 누가 모델 변경을 승인할 권한이 있고 어떤 문서화된 증거를 요구하는지 이름을 정하십시오. 시민 대면 결정 뒤의 모델을 문서 없이 교체하는 것이 바로 감사자가 정당화하라고 요구할 종류의 변경이기 때문입니다.

분야별 관점

스타트업. 만들 수 있는 가장 작고 정직한 평가를 만들고 제품과 함께 자라게 하십시오. 각각 검증된 기대 답이 있는 스무 개에서 마흔 개의 실제 사례 스프레드시트를 머지 전마다 스크립트로 돌리는 것이 여러분의 틈새에 대한 어떤 공개 벤치마크보다 낫고 비용이 거의 들지 않습니다. 손으로 채점하는 것이 실제로 아프기 전까지는 공유 플랫폼과 LLM 심사자를 건너뛰되, 같은 난처함이 두 번 일어나지 않게 하는 반사 신경이므로 사용자가 보고한 모든 실패를 첫날부터 세트에 접어 넣으십시오.

소기업. 평가 전문가가 없고 AI를 도구에 내장된 채 사 쓸 테니, 할 일은 증거를 만드는 것이 아니라 요구하는 것입니다. 각 벤더에게 품질을 어떻게 측정했는지, 여러분과 닮은 데이터로 테스트하는지, 여러분이 고르지 않은 업데이트 후 회귀를 어떻게 알아챌지 물으십시오. 도구를 직접 점검할 수 있도록 실제 사례의 작은 비공개 세트를 유지하십시오. 고객에게 닿은 틀린 자동 답은 그 확인에 드는 몇 분보다 훨씬 많은 비용이 들기 때문입니다.

대기업. 보상은 열두 팀이 각자 채점을 다시 발명하지 않도록 하는 공유 평가 플랫폼입니다. 골든 데이터셋의 공통 저장소, 지속적 통합에서 관문 통제되는 오프라인 스위트, 보정 점수와 함께 등록된 LLM 심사자 프롬프트, 기능별 온라인 지표입니다. 그 위에 필요한 기준과 릴리스 전 승인을 정하는 위험 등급으로 거버넌스를 얹어, 고위험 기능이 내부 보조 도구보다 높은 관문을 넘게 하십시오. 플랫폼은 팀 전반에 주석과 컴퓨트를 분할 상환하며, 이것이 모든 그룹이 즉흥적으로 하게 두기보다 하나를 구축해야 하는 가장 강한 이유입니다.

정부. 평가는 그저 수행되는 것이 아니라 감사 가능해야 하므로, 모든 릴리스에 대해 데이터셋 버전, 지표, 리뷰어의 이름, 승인을 책무의 증거로 보관하십시오. 레드팀 스위트는 시스템이 출처에 없는 정책을 지어내거나 법을 진술하기를 거부함을 입증해야 하며, 조달은 벤더에게 모델을 어떻게 평가했는지 공개하고 평가 데이터의 이식성을 보장하도록 요구해야 합니다. 감독 기관이 도구가 안전하다는 것을 어떻게 아는지 물을 때, 답은 안심시키는 말이 아니라 날짜가 적힌 기록이어야 합니다.

사례

스타트업. AI 계약 검토 보조 도구를 만드는 네 명의 회사는 각각 표시해야 할 위험을 사내 변호사가 레이블링한 실제 조항 마흔 개의 스프레드시트로 시작했습니다. 모든 프롬프트 변경은 머지 전에 스크립트로 그 세트에 대해 돌았고, 점수는 풀 리퀘스트에 출력되었습니다. 사용자가 놓친 조항을 표시하면 곧장 시트에 들어가, 세트가 제품과 함께 자랐습니다. 물량이 늘자 설명 품질을 채점하려고 LLM 심사자를 더했지만, 표본에서 변호사와 일치하는지 확인한 뒤에야 그랬습니다. 싸고, 비공개이고, 정직한 것이 그들의 틈새에서 어떤 공개 벤치마크보다 나았습니다.

기업. 한 대형 은행이 지원, 검색, 내부 도구에 걸쳐 열두 개의 AI 기능을 운영했는데 팀마다 채점이 달랐습니다. 그들은 공유 평가 플랫폼을 구축했습니다. 골든 데이터셋을 저장하고, CI에서 오프라인 스위트를 돌리고, 보정 점수와 함께 LLM 심사자 프롬프트를 등록하고, 기능별 온라인 지표를 추적하는 공통의 자리입니다. 그 위에 필요한 기준과 릴리스 전 필요한 승인을 정하는 위험 등급으로 거버넌스가 얹혔습니다. 새 사기 설명 기능은 평가 세트가 리뷰되고, 레드팀 스위트가 통과하고, 책임 있는 소유자가 결과에 서명하기 전에는 출하될 수 없었습니다. 플랫폼을 재사용하자 팀들은 측정 방법이 아니라 자기 영역에 대해 논쟁했습니다.

정부. 한 공중 보건 기관이 직원이 승인된 안내로 급여 질문에 답하도록 돕는 보조 도구를 배포했습니다. 틀린 답이 누군가의 자격에 영향을 줄 수 있으므로 평가는 감사 가능해야 했습니다. 모든 릴리스가 흔한 질문, 엣지 케이스, 적대적 프롬프트를 덮는 문서화된 평가 세트를 돌렸고, 결과, 데이터셋 버전, 지표, 리뷰어의 이름이 책무의 증거로 보관되었습니다. 레드팀 스위트는 시스템이 출처에 없는 정책을 지어내거나 법을 진술하기를 거부하는지 확인했습니다. 감독 기관이 기관이 도구가 안전하다는 것을 어떻게 아는지 물었을 때, 답은 안심시키는 말이 아니라 날짜가 적힌 기록이었습니다.

비즈니스 사례: 동기, ROI, TCO

평가는 다른 모든 AI 투자를 더 안전하고 빠르게 만들어 스스로를 보상합니다. 투자수익률(ROI)은 더 적은 프로덕션 사고, 팀이 자신감을 갖고 프롬프트와 모델을 바꿀 수 있어 더 빠른 반복, 도움이 되는지 입증할 수 있어 더 나은 모델을 나오는 날 채택하는 능력으로 나타납니다. 가치를 매기는 가장 분명한 방법은 그것이 없는 비용입니다. 단 한 번의 공개적 환각, 편향된 출력, 데이터 유출이 수년의 평가 인프라보다 훨씬 많은 수습 비용, 잃은 신뢰, 규제 노출을 치를 수 있습니다. 그것은 CI에서 공짜로 회귀를 찾는 것과 신문에서 찾는 것의 차이입니다.

총소유비용(TCO)은 실제이며 이름을 댈 가치가 있습니다. 주석 노동, 자동 심사자가 소비하는 컴퓨트, 사용이 이동함에 따라 평가 세트를 대표적으로 유지하는 지속적 작업에 값을 치릅니다. 기업 규모에서는 공유 플랫폼이 이 대부분을 많은 팀에 분할 상환하며, 이것이 모든 그룹이 즉흥적으로 하게 두기보다 하나를 구축해야 하는 가장 강한 논거입니다. 구체적 위험(여러분 영역의 나쁜 공개 답 하나의 비용)을 구체적 역량(각 새 모델을 안전하게 채택하는 속도)과 짝지우고, 평가를 조직이 무모하게 움직이지 않고 빠르게 움직이게 하는 통제로 구성하여 리더십을 설득하십시오.

안티패턴과 함정

느낌 기반 출하. 데이터셋도 반복 가능한 점수도 없이 몇 개의 프롬프트를 손으로 시도해 AI 변경을 판단하는 것.
벤치마크 연극. 오염과 분포 불일치를 무시하고, 강한 공개 벤치마크 점수를 시스템이 과업에 맞는다는 증명으로 신뢰하는 것.
평가 세트에 과적합. 새 보류 세트 없이 숫자가 높고 무의미해질 때까지 같은 고정 세트에 대해 프롬프트를 튜닝하는 것.
보정되지 않은 심사자. LLM 심사자를 배포하고 사람 채점자와의 일치를 한 번도 확인하지 않은 채 그 점수를 신뢰하는 것.
지표 숭배. BLEU나 ROUGE를 품질인 것처럼 최적화하고, 참조 텍스트와 우연히 겹치는 더 나쁜 답을 출하하는 것.
일회성 레드팀. 출시 전 시스템을 한 번 공격하고 발견을 영구 회귀 테스트로 바꾸지 않는 것.
오프라인만의 확신. 좋은 오프라인 점수가 기능이 동작한다는 뜻이라 믿으며, 실제 성과의 온라인 측정이 없는 것.
고아가 된 평가 세트. 아무도 소유하지 않아 프로덕션 실패를 결코 흡수하지 않고 서서히 현실을 반영하지 않게 되는 데이터셋.

성숙도 모델

1단계, 시작: AI 변경이 누군가 우연히 걱정할 때 반응적으로 몇 개의 예시에 대해 손으로 판단됩니다. 데이터셋도, 반복 가능한 점수도, 관문도 없습니다. 회귀는 사용자가 발견하고, 아무도 시스템이 지난달보다 나은지 나쁜지 말할 수 없습니다.
2단계, 발전: 일부 팀이 작은 골든 데이터셋을 유지하고 큰 변경 전에 수동으로 돌리며, 몇 개의 고전적 또는 참조 기반 점수가 있습니다. 사람 리뷰가 중요한 기능에 있지만 채점은 팀마다 일관되지 않고, 평가는 자동화되거나 관문 통제되지 않으며, 각 그룹이 다르게 합니다.
3단계, 표준화: 오프라인 스위트가 모든 프롬프트, 모델, 검색 변경마다 지속적 통합에서 돌고 머지를 관문 통제하며, 조직 전체에 하나의 문서화된 실천을 따릅니다. LLM 심사자는 사람 레이블에 대해 보정되고, 레드팀은 반복 가능한 스위트이며, 데이터셋은 소유되고, 버전 관리되고, 프로덕션 실패로 채워지며, 오염을 적극적으로 막습니다.
4단계, 관리: 평가가 기준선에 대해 데이터로 측정되고 통제됩니다. 심사자-사람 일치율, 레드팀 통과율, 세그먼트별 점수, 온라인 과업 성공, 드리프트가 시간에 따라 추적되고, 머지는 단일한 완벽한 실행이 아니라 임계값과 회귀 폭으로 관문 통제됩니다. 주석 비용과 실행당 컴퓨트는 기능별로 예산이 잡히고, 재보정은 일정에 따라 이루어지며, 각 결과에는 책임 있는 소유자와 승인이 붙습니다.
5단계, 오케스트레이션: 공유 평가 플랫폼이 조직 전체를 섬기고, 오프라인과 온라인 평가가 비즈니스 성과에 묶인 지속적인 루프를 이룹니다. 새 모델은 나오는 날 이식 가능한 평가 세트에 대해 입증되고, 포트폴리오는 사용과 위험이 이동함에 따라 적응하며, 평가 증거는 규제 기관과 감독을 위해 감사 가능하고, 한 팀의 실패에서 얻은 교훈이 모든 팀의 데이터셋으로 흘러갑니다.

논의를 위한 아이디어

오프라인 점수가 온라인 실험을 정당화할 만큼 강하다고 언제 판단하며, 언제 그렇지 않다고 판단합니까?
여러분의 위험 프로필에 맞는 사람 평가 대 자동 채점의 비율은 얼마이며, 얼마나 자주 다시 검토해야 합니까?
공개 벤치마크와 비공개 평가 세트가 어느 모델이 나은지에 대해 엇갈릴 때, 어느 쪽을 신뢰하며 이유는 무엇입니까?
CI에서 돌리기에 너무 느려질 만큼 부풀리지 않으면서 사용자 행동이 이동함에 따라 평가 세트를 어떻게 대표적으로 유지합니까?
여러분 영역의 레드팀 스위트에는 무엇이 들어가야 하며, 공격을 설계할 자격이 있는 사람은 누구입니까?
모든 단계를 채점하는 비용에 빠지지 않으면서 에이전트의 최종 답만이 아니라 궤적을 어떻게 평가합니까?

핵심 요점

AI 평가는 출력이 비결정적이고 정답이 하나인 경우가 드물어 소프트웨어 테스트와 다르므로, 정확한 값을 단언하는 대신 대표적 사례 전반에 걸쳐 품질을 측정합니다.
평가 주도 개발을 실천하십시오. 측정 가능한 품질을 먼저 정의한 뒤 그것을 향해 만들고, 모든 프로덕션 실패를 세트에 접어 넣으십시오.
방법을 속도와 충실도로 층층이 쌓으십시오. 지속적 반복에는 싼 자동 채점, 닻으로서의 사람의 판단, 둘을 정렬하는 보정입니다.
오염과 과적합에 대비하십시오. 그러지 않으면 실제 시스템이 사용자를 실망시키는 동안 숫자가 여러분에게 아첨합니다.
오프라인 평가를 CI에 관문으로 연결하고 프로덕션에서 품질과 드리프트를 계속 측정하십시오. 출시 때 좋았던 모델도 쇠퇴할 수 있습니다.

참고 문헌과 더 읽을거리

Chip Huyen, AI Engineering: Building Applications with Foundation Models.
Lianmin Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena.
Kishore Papineni et al., BLEU: A Method for Automatic Evaluation of Machine Translation.
Chin-Yew Lin, ROUGE: A Package for Automatic Evaluation of Summaries.
Percy Liang et al., Holistic Evaluation of Language Models (HELM).
Deep Ganguli et al., Red Teaming Language Models to Reduce Harms: Methods, Scaling Behaviours, and Lessons Learned.
OWASP Foundation, OWASP Top 10 for Large Language Model Applications.
National Institute of Standards and Technology, AI Risk Management Framework.