평가 플랫폼 구축: 보이는 것보다 어렵다

그는 이 품질을 유지하기 위한 두 가지 주요 축으로 에이전트가 프로덕션에 도달하기 전에 동작을 테스트하는 '평가(Evals)'와 에이전트가 실제 사용자와 함께 작동할 때 지속적인 모니터링에 중점을 둔 '관찰 가능성(Observability)'을 제시합니다. 팀의 궁극적인 목표는 AI 에이전트가 실제 사용자와 상호 작용할 때 신뢰를 유지하는 것입니다.

LLM은 비결정적이고 가변성이 매우 높아 상당한 유연성을 제공하지만 예측 불가능한 특성으로 인해 상당한 위험을 초래합니다.

이러한 가변성을 확인하지 않으면 일관성 없는 에이전트 동작으로 이어져 브랜드 손상, 규정 준수 문제, 유지보수 비용 증가를 초래할 수 있습니다. 평가는 이러한 불확실성을 완화하고 배포 전에 에이전트가 예측 가능하게 작동하도록 보장하는 데 중요합니다.

많은 팀은 초기 워크플로우에서 스프레드시트 기반 평가를 일반적이고 수용 가능한 첫 단계로 채택합니다.

기본 평가 시스템에는 특정 입력에 대해 에이전트를 실행하는 기능, 결과를 보는 메커니즘, 테스트 예제 모음이라는 세 가지 기본 구성 요소가 필요합니다. 후세인은 스프레드시트가 초기 단계에 유용하지만, 포괄적인 평가 요구 사항에 있어서는 '빙산의 일각'에 불과하며, 확장을 위해서는 더욱 강력한 도구가 필요하다고 주장합니다.

전문적인 평가 시스템은 우수한 데이터셋, 자동화된 채점, 디버깅 도구, 프로덕션 성능을 개발에 다시 연결하는 통합 피드백 루프를 필요로 합니다. 이러한 확장된 범위는 기본적인 테스트를 넘어 발전하는 데 필수적입니다.

LLM은 비결정적 특성 때문에 기존 소프트웨어와 근본적으로 다르므로 기존의 단위 및 회귀 테스트로는 지속적인 행동 변화를 관리하기에 불충분합니다.

효과적인 평가에는 소프트웨어 엔지니어, AI 엔지니어, 이제 평가에 참여하는 제품 관리자(PM), 도메인 전문 지식을 제공하는 주제 전문가(SME)를 포함하는 교차 기능 팀이 필요합니다. 이 지속적인 프로세스는 평가를 에이전트 품질을 개선하기 위한 지속적인 '언덕 오르기' 워크플로우로 전환합니다.

사용자 상호 작용과 모델 동작이 지속적으로 진화하기 때문에 이러한 지속적인 반복은 필수적이며, 이는 기존 머신러닝에서 관찰되는 드리프트를 반영합니다. 플라이휠 메커니즘은 새로운 회귀를 의도치 않게 도입하지 않고도 품질 개선이 구현되도록 보장합니다.

설정은 간단하며, 에이전트 출력을 관찰하기 위해 입력과 실행의 간단한 루프를 포함합니다. 그러나 이 방법은 시간이 지남에 따라 데이터를 분석하는 데 어려움이 있고, 협업 노력에 한계가 있으며, 중요한 도메인 전문가의 입력을 배제하기 때문에 빠르게 유용성이 감소합니다.

제품 엔지니어는 제품 관리자를 평가 루프에 통합하기 위해 종종 맞춤형 내부 UI를 개발하여 결과의 시각적 표현을 개선합니다.

더 나은 시각화에도 불구하고 이러한 UI는 주로 '보고 도구'로 기능하며, 협업 문제와 영구 데이터에 대한 장기 분석 수행의 어려움으로 인해 여전히 고군분투하며, 심층적인 반복 개선을 위한 효율성을 제한합니다.

평가 플랫폼의 발전으로 비기술적인 사용자도 시스템 프롬프트, 모델 및 매개변수를 조정할 수 있으며, 나란히 비교 기능이 표준이 되었습니다.

이러한 발전에도 불구하고 중요한 격차가 남아 있습니다. 즉, 실제 에이전트 동작을 이해하기 위한 프로덕션 환경에 대한 가시성이 부족합니다. 강력한 프로덕션 원격 측정 기능이 없는 팀은 효과적으로 '맹목적으로 운영'하며 에이전트의 실제 영향을 완전히 평가할 수 없습니다.

스프레드시트를 사용한 초기 평가는 개념 증명에 적합하지만, 데이터 규모가 커지면 빠르게 관리할 수 없게 되어 평가 플랫폼 구축이 단순히 UI/UX 문제가 아니라 복잡한 시스템 문제임을 입증합니다.

에이전트 추적은 방대한 준구조화된 JSON 객체이며, 종종 수백 메가바이트에 달하여 기존 클라우드 데이터 웨어하우스가 엄청난 양과 중첩된 구조로 인해 실패합니다. 개발자는 실시간 쿼리 및 장기 분석 작업을 위한 사용자 지정 인프라를 유지 관리해야 하는 부담을 안게 됩니다.

BTQL과 같은 사용자 지정 추상화 계층을 개발하는 것은 또 다른 기술적 복잡성을 야기합니다. 이는 내부 평가 플랫폼이 이러한 데이터를 대량으로 복잡하게 처리하는 고유한 어려움으로 인해 확장하는 데 어려움을 겪는 경우가 많다는 점을 강조합니다.

AI 에이전트 페이로드는 기존의 킬로바이트 크기 하트비트 로그를 훨씬 초과하는 수십에서 수백 메가바이트에 달하기 때문에 상당한 기술적 문제를 야기합니다.

데이터 구조는 깊이 중첩되고 준구조화되어 텍스트 쿼리를 복잡하게 만들고 대규모 집계와 정확한 특정 시점 스냅샷을 모두 지원하는 읽기 패턴이 필요합니다. 시스템은 AI 엔지니어, 제품 관리자 및 주제 전문가의 접근을 동시에 수용해야 합니다.

코딩 에이전트는 최근 데이터를 분석하여 열악한 사용자 경험을 사전에 식별하고 평가를 트리거하여 무언의 실패나 반복적인 사용자 불만과 같은 '알 수 없는 미지수'의 발견을 자동화할 수 있습니다. 개선 루프는 수동 개입에서 에이전트가 제안하는 반복으로 진화하고 있으며, 인간의 책임은 결과를 검토하고 배포할 버전을 선택하는 것으로 전환되고 있습니다.

코딩 에이전트는 기본 인프라 및 코드베이스에 대한 액세스를 활용하여 평가를 실행하고 결과를 기록하는 핵심 메커니즘 역할을 합니다.

목표는 개발자가 자연어 프롬프트를 사용하여 "지난 24시간 동안 사용자 경험이 좋지 않았던 모든 추적을 찾아주세요. 저를 위해 평가를 실행해 주세요."와 같은 작업을 시작할 수 있는 헤드리스 경험을 만드는 것입니다.

엔지니어와 제품 관리자의 수동 평가는 Braintrust가 자동화하려는 힘든 과정입니다.

로깅된 추적 데이터에 대한 추론을 실행함으로써 플랫폼은 인사이트와 '알 수 없는 미지수'를 자동으로 표면화하고, 무언의 실패 또는 좌절로 인한 반복적인 사용자 프롬프트 사례를 식별하여 수동 프로세스를 넘어 확장된 작업을 달성합니다.

기본 데이터베이스, 권한 관리 및 데이터 마스킹은 단순한 UI 또는 스프레드시트를 넘어서는 플랫폼을 생성하기 위한 중요한 요구 사항입니다. 이러한 각 구성 요소는 평가가 시스템 엔지니어링 도전으로 기능해야 하는 방법을 강조합니다.

주요 백엔드 구성 요소에는 기본 데이터베이스, 제어 및 권한에 대한 포괄적인 관리, 안전한 데이터 마스킹 기능이 포함됩니다. 플랫폼은 또한 코딩 에이전트가 애플리케이션 변경을 제안하는 반복적인 개선 루프를 지원해야 하며, 궁극적으로 인간의 책임을 결과를 검토하고 프로덕션에 배포할 버전을 선택하는 것으로 전환해야 합니다.