Anthropic Simon 검색어가 AI 평가에 대한 더 작은 접근인 smevals를 만나다

Simon Willison은 수년간의 eval 실험 끝에 smevals를 공개하며, AI 에이전트 테스트에 관한 Anthropic의 보다 공식적인 가이드와 새로운 대비를 만들었다. anthropic simon 연결이 중요한 이유는 양측이 이제 같은 문제를 강조하기 때문이다. 팀이 프롬프트, 도구, 시스템 지침, 그리고 모델을 둘러싼 하니스까지 테스트하지 않는다면 모델 점수만으로는 알 수 있는 것이 거의 없다.

Willison은 Jesse Vincent의 응용 AI 연구소 Prime Radiant와 함께 smevals를 만들었다. 이 프로젝트는 여러 구성에서 소규모 평가 스위트를 실행하고, 결과물을 채점하며, 자세한 검토를 위한 보고서를 생성한다.

이번 공개는 AI 평가에 대한 흔한 가정에 이의를 제기한다. 팀은 유용한 질문을 던지기 전에 반드시 대규모 벤치마크 플랫폼이 필요한 것은 아니다. 집중된 과제, 반복 가능한 구성, 명시적인 검사, 그리고 실패를 이해할 수 있을 만큼의 가시성이 필요하다.

이로써 핵심 경쟁 구도는 Anthropic과 다른 모델 제공업체 간의 대결보다 더 작고 실용적인 형태가 된다. 즉, 집중된 로컬 평가와 무겁고 범용적인 평가 인프라의 대결이다. 전자는 속도와 검증 가능성을 중시하고, 후자는 더 폭넓은 실험과 복잡한 환경을 지원한다.

smevals가 소규모 AI 평가를 위해 바꾼 것

smevals는 구체적인 제품 질문을 과제, 구성, 채점 규칙으로 이루어진 이식 가능한 디렉터리로 전환한다.

Willison은 2026년 7월 31일 smevals를 발표했다. 그의 smevals 개요는 이를 서로 다른 모델 구성에서 소규모 eval 스위트를 실행하고 결과 출력을 채점하는 도구로 설명한다.

기본 워크플로는 uvx smevals docs로 시작한다. 이 명령은 코딩 에이전트에 프로젝트 문서를 제공하여, 평가 스위트를 구축하기 전에 형식을 학습할 수 있게 한다.

이 접근법은 문서를 운영 맥락으로 취급한다. 사용자가 모든 구성 필드를 외우도록 요구하는 대신, 프로젝트는 코딩 에이전트가 지침을 읽고 파일 생성을 돕는 방식을 전제한다.

평가는 YAML 파일이 담긴 디렉터리 안에 존재한다. YAML은 구성에 자주 사용되는 사람이 읽기 쉬운 데이터 형식이다. 이 파일들은 질문, 과제, 모델 구성, 채점 방식을 설명한다.

사용자는 같은 스위트를 여러 모델에 대해 실행할 수 있다. Willison의 예시는 반복되는 -m 인수를 통해 이름이 지정된 GPT 및 Claude 구성을 비교한다.

이 명령 구조는 중요하다. 모델 선택을 제품 전체로 취급하는 대신, 더 큰 실험 안의 하나의 변수로 규정하기 때문이다.

smevals는 실행과 채점도 분리한다. run 명령은 구성이 과제를 시도했을 때 어떤 일이 일어났는지 기록한다. 이후 grade 명령은 기록된 결과에 정의된 검사를 적용한다.

이 분리는 유용한 감사 경계를 만든다. 팀은 원시 동작을 보존하고, 채점 로직을 수정하며, 다른 루브릭이 해석을 어떻게 바꾸는지 검토할 수 있다.

이 도구는 두 가지 보고 경로를 제공한다. serve 명령은 로컬 웹 인터페이스를 시작하고, build는 다른 곳에 호스팅할 수 있는 정적 HTML을 생성한다.

Willison은 하이쿠 평가로 워크플로를 시연했다. 보고서는 모델이 비어 있지 않은 정확히 세 줄을 생성했는지 확인하고, 결과 채점을 바탕으로 구성을 순위화했다.

하이쿠 벤치마크는 의도적으로 소박하다. 그럼에도 진지한 평가 원칙을 보여 준다. 좁게 정의된 요구사항은 광범위한 선호도 점수로는 설명할 수 없는 차이를 드러내는 경우가 많다.

이번 공개는 일관된 용어도 도입한다. eval은 과제를 포함하고, 구성은 검토 대상인 모델과 기타 변수를 정의한다.

실행은 하나의 구성이 하나의 과제를 시도한 기록이다. 채점기는 결정론적 검사나 맞춤형 검사 스크립트를 포함한 검사를 적용해 등급을 생성한다.

이 맞춤형 검사는 문자열을 살펴보고, XML 같은 형식을 검증하거나, 다른 모델을 호출해 판단을 내릴 수 있다. 이 범위 덕분에 하나의 스위트에서 객관적 제약과 보다 주관적인 품질 평가를 결합할 수 있다.

이 워크플로 어디에도 smevals가 Anthropic 제품이라는 근거는 없다. anthropic simon 연관성은 기업 소유가 아니라 에이전트 평가와 Claude 구성에 대한 관심이 겹친 데서 비롯된다.

따라서 즉각적인 변화는 접근성이다. 이제 개발자는 광범위한 평가 서비스를 먼저 도입하거나 맞춤형 대시보드를 구축하지 않고도 작은 평가 질문을 패키징할 수 있다.

Anthropic Simon 관심이 이제 하니스에 집중되는 이유

주변 에이전트 하니스가 결과를 바꿀 수 있기 때문에, 모델은 더 이상 유일하게 의미 있는 비교 단위가 아니다.

Anthropic은 에이전트 하니스를 입력을 처리하고, 도구 호출을 조율하며, 결과를 반환하는 시스템으로 정의한다. Anthropic의 에이전트 eval 가이드는 이 계층을 실험을 실행하고 채점하는 평가 하니스와 구분한다.

이 구분은 smevals가 모델 이름을 넘어선 구성을 지원하는 이유를 설명하는 데 도움이 된다. 구성에는 서로 다른 시스템 프롬프트, 모델 파라미터, 또는 에이전트 하니스도 포함될 수 있다.

두 코딩 제품이 같은 기반 모델을 사용한다고 가정해 보자. 한 제품은 모델에 더 나은 저장소 맥락을 제공하고, 다른 제품은 더 강력한 도구와 더 명확한 완료 검사를 제공한다.

모델 전용 벤치마크라면 이 시스템들을 동등하게 취급할 것이다. 구성 수준 평가는 실제 동작이 다르다는 점을 보여 줄 수 있다.

압박은 여전히 공개 리더보드만으로 모델을 선택하는 AI 제품 팀에 가해진다. 이 순위는 후보군을 좁히는 데 도움을 줄 수 있지만, 제품의 정확한 프롬프트, 도구, 권한, 데이터를 재현하는 경우는 드물다.

에이전트 동작은 여러 단계에 걸쳐 전개되기도 한다. 시스템은 도구를 호출하고, 상태를 수정하고, 결과를 해석한 뒤, 계속할지 결정할 수 있다.

초기 오류 하나가 이후의 모든 행동에 영향을 줄 수 있다. 이 때문에 에이전트 평가는 챗봇이 질문 하나에 올바르게 답했는지를 확인하는 것과 다르다.

Anthropic의 가이드는 팀이 에이전트를 평가할 때 모델과 에이전트 하니스를 함께 평가한다고 말한다. 이 관점은 smevals가 사용하는 구성 모델과 밀접하게 일치한다.

이러한 중첩이 실제 anthropic simon 이야기다. 두 접근법 모두 고립된 모델 지능에서 벗어나 사용자가 경험하는 완전한 시스템으로 관심을 옮긴다.

이 시점은 커져 가는 운영 문제도 반영한다. 모델, 프롬프트, 하니스는 독립적으로 바뀌지만, 제품 팀은 여전히 무엇이 회귀를 일으켰는지 파악해야 한다.

새 모델은 추론 능력을 개선하면서 출력 스타일을 바꿀 수 있다. 수정된 시스템 프롬프트는 장황함을 줄이지만 지시 준수 능력을 약화시킬 수 있다. 하니스 업데이트는 더 나은 도구를 노출하는 동시에 상태 오류를 도입할 수 있다.

통제된 구성이 없다면 이런 변화는 서로 얽힌다. 팀은 제품의 느낌이 달라졌다는 점은 알지만, 그 차이를 자신 있게 귀속할 수는 없다.

Anthropic은 이 상태를 충분한 가시성 없이 운영하는 것으로 설명한다. 팀은 사용자 불만을 기다리고, 실패를 수동으로 재현하며, 한 문제를 패치한 뒤 또 다른 회귀를 만들 위험을 감수한다.

smevals는 같은 문제에 더 작은 대응책을 제시한다. 모든 프로덕션 조건을 재현하려 하지는 않는다. 대신 팀이 실험을 확장하기 전에 질문 하나를 분리할 수 있는 구조화된 방식을 제공한다.

이는 지식 집약적 업무에 중요하다. 엔지니어링 팀은 어시스턴트가 코드를 생성하기 전에 올바른 내부 명세를 찾는지 테스트할 수 있다.

이 테스트는 두 검색 프롬프트, 두 모델 버전, 또는 두 도구 정책을 비교할 수 있다. 검색 가능한 지식 기반을 유지하는 팀은 문서 접근 방식이 바뀔 때마다 비슷한 질문에 직면한다.

그 결과 비교는 어느 모델이 최고인지를 묻는 것보다 더 유용하다. 명시된 조건에서 어떤 완전한 구성이 정의된 과제를 수행하는지를 묻는다.

핵심 메커니즘은 더 똑똑한 점수가 아니라 분리다

smevals는 과제, 실행, 채점, 보고를 독립적으로 검토할 수 있을 만큼 분리함으로써 명확성을 얻는다.

많은 평가 제품은 비교를 쉽게 만드는 단일 점수를 약속한다. 이러한 편의성은 그 점수를 만들어 낸 판단을 숨길 수 있다.

smevals는 더 세분화된 경로를 택한다. eval은 더 큰 질문을 명시하고, 각 과제는 구체적인 도전을 제시한다.

그런 다음 구성은 해당 과제를 시도하는 시스템을 설명한다. 실행은 시도를 포착하고, 채점기는 하나 이상의 검사를 통해 저장된 결과를 평가한다.

이 아키텍처는 대체로 일반적인 테스트 논리를 따르기 때문에 일반적인 테스트처럼 들린다. 입력, 조건, 출력, 단언, 보고서는 여전히 익숙한 개념이다.

언어 모델의 동작은 각 구성 요소를 복잡하게 만든다. 같은 프롬프트가 다른 답변을 낼 수 있고, 여러 다른 답변이 모두 사용자를 만족시킬 수 있다.

따라서 유용한 검사는 요구사항에 맞아야 한다. 고정 토큰에는 정확한 문자열 일치가 적합하지만, 여러 표현이 유효할 때는 성능이 떨어진다.

구조적 검사는 또 다른 선택지다. 팀은 JSON, XML, 줄 수, 필수 섹션, 또는 에이전트 환경 안에서 생성된 파일을 검증할 수 있다.

모델 기반 채점기는 덜 결정론적인 품질을 다룬다. 다른 모델이 답변이 루브릭을 따르는지, 필요한 추론을 포함하는지, 또는 스타일 요구사항을 충족하는지 평가할 수 있다.

하지만 AI 심사자가 주관적 질문을 객관적 진실로 바꾸지는 않는다. 평가에 또 다른 모델, 프롬프트, 가정의 집합을 도입할 뿐이다.

채점과 실행을 분리하면 이 한계를 더 쉽게 조사할 수 있다. 팀은 같은 실행 기록을 보존하고, 매번 모든 과제를 다시 실행하는 비용 없이 여러 채점 방식을 비교할 수 있다.

불일치도 검토할 수 있다. 형식 검사는 통과했지만 AI 심사자는 실패 판정을 내린다면, 보고서는 이를 즉시 평균 내는 대신 두 가지 서로 다른 차원으로 드러낸다.

보고 계층도 같은 이유로 중요하다. 종합 점수는 독자가 결과를 훑는 데 도움이 되지만, 개별 실행 기록은 한 구성이 성공하거나 실패한 이유를 보여 준다.

Willison의 하이쿠 예시는 이 균형을 보여 준다. 리더보드는 요약을 제공하고, 최근 실행, 과제 세부 정보, 태그, 채점기 정보는 그 바탕이 되는 증거를 드러낸다.

정적 HTML은 또 다른 실용적 이점을 더한다. 팀은 라이브 평가 서비스를 유지하지 않고도 결과를 게시할 수 있다.

uvx 진입점도 설정 마찰을 낮춘다. 공식 uv 도구 가이드에 따르면, uvx는 임시 격리 환경에서 패키지 도구를 실행한다.

이 설계는 짧은 조사에 적합하다. 개발자는 영구적인 전역 설치를 첫 번째 조건으로 삼지 않고도 명령을 시도할 수 있다.

코딩 에이전트 워크플로는 또 다른 설정 비용을 줄인다. 에이전트는 프로젝트 문서를 읽고, YAML 파일을 제안하며, 테스트 개선을 도울 수 있다.

인간 검토는 여전히 필요하다. 에이전트가 생성한 스위트는 모호한 기대를 담거나, 어려운 사례를 빠뜨리거나, 자신의 가정만 보상하는 검사를 만들 수 있다.

따라서 이 도구가 평가 설계를 없애 주는 것은 아니다. 질문과 그 질문의 첫 실행 가능한 버전 사이의 거리를 줄여 준다.

이 차이는 중요하다. 팀은 흔히 첫 단계에 데이터베이스, 대시보드, 추적 시스템, 대규모 골든 데이터셋이 필요하다고 생각하기 때문에 평가를 미룬다.

smevals는 더 좁은 첫 단계를 제안한다. 실제 불확실성 하나를 인코딩하고, 몇 가지 통제된 구성에서 실행하는 것이다.

소규모 eval 스위트가 대형 프레임워크에 도전하다

smevals의 가장 강력한 장점은 기능의 폭이 아니라, 범위가 제한된 질문으로 시작하면서 증거를 유지할 수 있다는 능력이다.

평가 시장에는 이미 더 폭넓은 오픈 프레임워크가 포함되어 있습니다. 영국 AI Security Institute의 Inspect 플랫폼은 데이터셋, 솔버, 스코어러, 에이전트, 샌드박스, 모델 제공업체, 상세 트랜스크립트를 지원합니다.

Inspect 문서에서는 작업을 데이터셋, 솔버, 스코어러의 조합으로 설명합니다. 솔버는 한 번의 모델 호출을 수행하거나 도구를 사용하는 멀티턴 에이전트로 작동할 수 있습니다.

Inspect는 복잡한 보안 평가와 격리된 실행 환경도 지원합니다. 이러한 기능은 정식 벤치마크를 운영하거나 외부 상태를 변경하는 에이전트를 테스트하는 조직에 적합합니다.

Promptfoo는 프롬프트와 애플리케이션 테스트 관점에서 문제에 접근합니다. 해당 구성 형식은 제공업체, 프롬프트, 테스트 케이스, 어설션, 변수를 포괄합니다.

공식 평가 워크스페이스는 YAML로 제공업체, 프롬프트, 기대 동작을 정의하는 방식을 보여줍니다. 이 때문에 Promptfoo는 이미 프롬프트를 테스트 가능한 코드처럼 다루는 팀에 적절한 비교 대상이 됩니다.

smevals는 더 작은 범위를 표방하며 이 분야에 진입합니다. 사용자가 더 많은 기능을 요청하는 상황에서도 그 작은 범위가 일관성을 유지할 수 있는지가 장점의 핵심입니다.

집중된 스위트는 검토하기가 더 쉬울 수 있습니다. 모든 작업은 제품 결정과 직접 연결될 수 있고, 모든 구성은 팀이 실제로 출시할 수 있는 변경 사항을 나타낼 수 있습니다.

이러한 집중은 실패 분석도 개선합니다. 구체적인 사용자 요구를 중심으로 이름 붙인 테스트는 추상적인 역량 범주보다 개발자에게 더 많은 정보를 제공합니다.

주간 제품 업데이트를 작성하는 어시스턴트를 생각해 보겠습니다. 작은 스위트는 올바른 회의 노트를 인용하는지, 결정 사항과 제안을 구분하는지, 근거 없는 주장을 피하는지를 테스트할 수 있습니다.

구성에서는 검색 프롬프트, 모델, 문서 선택 도구를 달리할 수 있습니다. 채점기는 인용 존재 여부, 출처 식별, 사실 일관성을 확인할 수 있습니다.

공개 벤치마크는 이런 제품 질문에 답하지 못합니다. 팀의 문서, 예상 워크플로, 유용한 업데이트의 정의가 빠져 있기 때문입니다.

환경 자체에 시뮬레이션이 필요한 경우에는 대규모 프레임워크가 여전히 가치 있습니다. 브라우저 에이전트, 코딩 에이전트, 고객 서비스 시스템에는 재현 가능한 데이터베이스나 샌드박스를 갖춘 상태 유지형 작업이 필요한 경우가 많습니다.

작은 YAML 스위트가 이런 조건을 자동으로 재현하는 것은 아닙니다. 호환되는 러너, 스크립트, 픽스처 또는 기타 하네스 구성 요소가 필요합니다.

그래서 주요 경쟁자는 특정 회사가 아니라 접근 경로입니다. 좁은 질문으로 로컬에서 시작할지, 범용 평가 인프라로 시작할지의 선택입니다.

어느 경로도 모든 경우에 이기지는 않습니다. 설정 비용 때문에 팀이 아무것도 테스트하지 못하는 상황에서는 작은 경로가 유리합니다.

테스트가 복잡한 상태를 제어하고, 전체 궤적을 기록하며, 격리를 강제하거나, 배포 파이프라인 안에서 지속적으로 작동해야 한다면 더 넓은 경로가 유리합니다.

가장 유용한 과정은 두 방식을 연결하는 것일 수 있습니다. 팀은 smevals로 가치 있는 사례를 발견한 뒤, 성숙한 테스트를 더 큰 회귀 시스템으로 이전할 수 있습니다.

이 과정은 아티팩트가 읽기 쉬운 상태로 유지될 때만 작동합니다. 다른 엔지니어가 재현할 수 있을 만큼 작업, 구성, 출력, 채점 규칙이 명확해야 합니다.

smevals는 이러한 이식성을 중심으로 설계된 것으로 보이지만, 이 관례가 유지될지는 도입이 결정할 것입니다. 맞춤형 채점기와 러너가 쌓이면 도구를 교체하기가 더 어려워집니다.

따라서 프로젝트의 작은 규모는 장점이자 시험대입니다. 모든 복잡한 평가 플랫폼을 재현하지 않으면서도 실제 에이전트를 위한 충분한 역량을 추가해야 합니다.

점수만으로는 여전히 결론 낼 수 없는 것

반복 가능한 스위트는 동작을 드러낼 수 있지만, 그 작업, 채점기, 샘플이 프로덕션 현실을 대표한다고 보장할 수는 없습니다.

첫 번째 불확실성은 커버리지입니다. 간결한 스위트는 좁은 질문에는 잘 답할 수 있지만, 평균 점수보다 더 중요한 드문 실패를 놓칠 수 있습니다.

팀은 이미 알고 있는 성공 사례를 중심으로 작업을 작성할 수도 있습니다. 평가를 생성하도록 요청받은 코딩 에이전트는 실제 사용자가 발견하는 놀라운 엣지 케이스를 찾지 못한 채 그럴듯한 변형만 만들어낼 수 있습니다.

따라서 프로덕션 인시던트는 스위트에 다시 반영되어야 합니다. 불만, 실패 트레이스, 지원 티켓, 수동 검토는 합성 작업 생성이 놓친 시나리오를 드러낼 수 있습니다.

두 번째 불확실성은 비결정성입니다. 구성이 바뀌지 않은 것처럼 보여도 모델은 반복 시도마다 다른 결과를 낼 수 있습니다.

작업당 한 번의 실행만으로는 신뢰할 수 있는 구성과 우연히 성공한 구성을 구별할 수 없습니다. 출력 분산이 결정에 영향을 미친다면 반복 시행이 필수적입니다.

Anthropic의 평가 가이드는 여러 시행에 걸친 성공률을 살펴볼 것을 권장합니다. 또한 모델이 평가자가 예상하지 못한 유효한 해결책을 찾을 수 있다고 경고합니다.

이는 까다로운 실패 모드를 만듭니다. 결과가 사용자에게 더 나은 가치를 제공하더라도, 경직된 채점기는 창의적인 결과에 불이익을 줄 수 있습니다.

반대 문제는 모델 채점기에서 발생합니다. 관대한 AI 심사자는 중요한 숨은 요구사항을 위반하는 유창한 출력을 받아들일 수 있습니다.

인간 보정은 이러한 오류를 식별하는 데 도움이 됩니다. 검토자는 통과와 실패를 살펴보고, 채점기 판단을 비교하며, 심사자가 잘못된 동작을 보상할 때 루브릭을 수정해야 합니다.

세 번째 불확실성은 시스템과 평가기 간 오염입니다. 코딩 에이전트가 작업, 프롬프트, 검사를 작성하는 데 도움을 주면 그 선호가 벤치마크를 형성할 수 있습니다.

관련 모델을 채점기로 사용하면 이 효과는 더 심해질 수 있습니다. 실제 유용성을 측정하지 못한 채 익숙한 표현이나 추론 패턴을 선호할 수 있습니다.

이것이 모델 채점을 무효로 만드는 것은 아닙니다. 등급이 루브릭, 심사자 구성, 검토 프로세스로 추적 가능해야 한다는 뜻입니다.

네 번째 문제는 통계적 신뢰도입니다. 세 가지 작업으로 구성된 스위트는 명백한 형식 회귀를 식별할 수 있지만, 모델 품질에 관한 폭넓은 주장을 뒷받침할 수는 없습니다.

smevals는 자신을 작은 평가 스위트라고 부르며, 독자도 이 경계를 유지해야 합니다. 보고서는 실행된 작업을 비교할 뿐, 관련 모델의 모든 역량을 비교하지는 않습니다.

팀은 로컬 결과를 보편적인 순위로 바꾸지 말아야 합니다. “구성 A가 8개의 제품 사례를 통과했다”는 뒷받침할 수 있습니다. “모델 A가 더 낫다”는 대개 그렇지 않습니다.

비용과 지연 시간도 비슷한 주의가 필요합니다. 더 높은 점수를 받는 구성은 더 긴 프롬프트, 더 많은 도구 호출, 또는 더 느린 추론 모드를 사용할 수 있습니다.

이런 요소가 제품에 중요하다면 스위트는 이를 기록하고 비교해야 합니다. 품질 점수만으로는 최선의 출시 선택을 결정할 수 없습니다.

보안 역시 평가 설계를 바꿉니다. 셸, 브라우저, 데이터베이스에 접근할 수 있는 에이전트에는 격리된 환경과 최종 상태에 대한 검사가 필요합니다.

트랜스크립트는 에이전트가 성공했다고 주장했음을 보여줄 수 있습니다. 실제 결과는 올바른 파일을 만들었는지, 의도한 레코드를 변경했는지, 금지된 작업을 피했는지에 달려 있습니다.

이러한 한계는 작은 평가에 반대하는 근거가 아닙니다. 작은 스위트가 신뢰할 수 있는 범위를 정의합니다.

anthropic simon의 수렴이 유용한 이유는 어느 접근도 집계된 숫자를 종착점으로 여기지 않기 때문입니다. 실행, 트레이스, 결과, 채점기 동작은 모두 검토할 가치가 있습니다.

Anthropic Simon의 중첩이 지속되는지를 보여줄 세 가지 신호

팀이 실제 하네스 결정을 비교하고, 채점기를 보정하며, 반복 가능한 근거를 보존하는 데 활용한다면 smevals는 출시 이후에도 의미를 가질 것입니다.

첫 번째 신호는 공개된 평가 스위트의 범위입니다. Haiku 형식화는 워크플로를 입증하지만, 에이전트 개발자에게는 도구, 상태, 다단계 완료를 포함하는 사례가 필요합니다.

프롬프트만 비교하는 스위트는 smevals를 기존 프롬프트 테스트 도구에 가깝게 유지할 것입니다. 코딩 또는 리서치 하네스를 비교하는 스위트는 더 폭넓은 포지셔닝을 뒷받침할 것입니다.

사용자가 가시적인 실행과 검사를 갖춘 재현 가능한 에이전트 사례를 공개한다면 판단은 더 강해집니다. 예시가 짧은 텍스트 형식화 작업에만 머문다면 약해집니다.

두 번째 신호는 채점기 보정입니다. 이 프로젝트는 결정론적 검사와 모델 기반 평가를 포함한 더 복잡한 체커 스크립트를 지원합니다.

이제 사용자는 이러한 등급을 인간 판단과 비교하는 방법이 필요합니다. 유용한 보고서는 불일치를 하나의 점수 안에 숨기기보다 드러내야 합니다.

팀이 채점을 다시 실행하고, 루브릭을 검토하며, 채점기가 변경된 이유를 문서화할 수 있다면 smevals의 사례는 강화됩니다. 리더보드가 근거에서 분리된다면 약화됩니다.

세 번째 신호는 일상적인 개발과의 통합입니다. 로컬 실험은 한 번의 통찰을 만들지만, 회귀 스위트는 미래의 변경을 보호합니다.

팀이 모델 업데이트, 프롬프트 편집, 도구 변경, 하네스 릴리스 후에 smevals를 실행하는지 살펴보십시오. 반복 사용은 작은 스위트가 지속 가능한 엔지니어링 자산이 될 수 있음을 보여줄 것입니다.

통합을 위해 모든 팀이 정교한 플랫폼을 구축할 필요는 없습니다. 공유 저장소, 검토된 YAML, 저장된 실행 기록, 일관된 릴리스 검증이면 충분할 수 있습니다.

초기 비교 이후 스위트가 오래되면 이 신호는 약해집니다. 오래된 벤치마크는 현재 제품을 반영하지 못한 채 자신감만 만들 수 있습니다.

개발자와 엔터프라이즈 구매자에게 실질적인 행동은 간단합니다. 현재 직관으로 내리고 있는 결정 하나를 식별한 뒤, 이를 검증할 수 있는 가장 작은 테스트를 정의하십시오.

그 결정은 Claude와 GPT의 비교일 수도 있지만, 두 개의 시스템 프롬프트나 두 가지 검색 전략의 비교일 수도 있습니다. 구성은 사용자가 실제로 경험하는 것을 반영해야 합니다.

첫 결과를 판정이 아니라 근거로 다루십시오. 실패를 검토하고, 채점기에 의문을 제기하며, 실제 업무에서 사례를 추가하고, 동작이 달라지는 경우 반복 시행하십시오.

지속되는 anthropic simon의 교훈은 하나의 작은 도구가 AI 평가를 해결한다는 데 있지 않습니다. 모델 선택, 프롬프트 설계, 하네스 동작은 함께 테스트되어야 한다는 점입니다.

여러분의 팀은 아직도 데모, 리더보드, 또는 직감에 따라 어떤 제품 결정을 내리고 있습니까? 그 불확실성을 집중된 스위트로 바꾸고, 실행 기록을 보존한 뒤, 근거가 답을 바꾸는지 확인하십시오.