coSTAR: Databricks에서 AI 에이전트를 빠르고 안정적으로 배포하는 방법

테스트 스위트 없이 코딩 도우미가 코드베이스를 리팩터링하도록 두지 않을 것입니다. 테스트 없이는 도우미가 눈을 감고 작업하는 것과 같습니다. 하나의 함수를 수정하고 다른 세 개를 조용히 망가뜨릴 수 있습니다. 테스트는 루프를 닫는 것입니다. 테스트를 실행하고, 실패를 관찰하고, 코드를 수정하고, 다시 실행합니다. 테스트가 없으면 확신이 없습니다.

Databricks에서는 Databricks 플랫폼의 새로운 기능(예: Genie Code의 데이터 엔지니어링, 추적 분석 및 머신러닝 기능)부터 OSS 프로젝트(예: MLflow 도우미) 및 내부 엔지니어링 워크플로(예: 온콜 지원 또는 자동 코드 검토자)에 이르기까지 광범위한 기능을 다루는 에이전트를 지속적으로 개발하고 배포합니다. 이러한 에이전트는 장기 실행 작업을 수행하고, 수천 줄의 코드를 생성하며, 다른 것들 중에서 새로운 데이터 및 AI 자산을 만들 수 있습니다. 초기에 몇 가지 기본 검사를 수행했지만, 확신을 가지고 반복할 수 있도록 포괄적인 자동화된 테스트 스위트가 부족했습니다. 이 게시물에서는 MLflow와 이를 중심으로 구축한 모범 사례인 coSTAR(결합된 시나리오, 추적, 평가, 개선) 방법론을 사용하여 이 격차를 어떻게 해소했는지 설명합니다. coSTAR는 두 개의 결합된 루프를 실행합니다. 하나는 심사위원을 인간 전문가의 판단과 일치시켜 신뢰할 수 있도록 하고, 다른 하나는 신뢰할 수 있는 심사위원을 사용하여 모든 테스트 시나리오를 통과할 때까지 에이전트를 자동으로 개선합니다.

그림: coSTAR 프레임워크는 두 개의 미러링된 STAR 루프(Scenario → Trace → Assess → Refine)를 실행합니다. 에이전트 루프(파란색)는 심사위원을 사용하여 추적을 자동 채점하고 심사위원과 일치하도록 에이전트를 개선합니다. 심사위원 루프(주황색)는 인간 전문가를 사용하여 추적을 채점하고 그들의 평가와 일치하도록 심사위원을 개선합니다. 두 루프 모두 동일한 시나리오와 추적을 공유합니다.

문제: 테스트 없는 코딩

초기에 저희의 개발 루프는 다음과 같았습니다. 에이전트를 실행하고, 출력을 수동으로 검토하고, 결함을 발견하고, 코딩 도우미에게 수정하도록 지시합니다. 반복합니다.

이것이 테스트 없이 코드를 작성하고 모든 변경 사항을 수동으로 QA하는 것과 비슷하게 들린다면, 그것은 정확히 그것이었습니다. 그리고 예상대로 실패했습니다. 명백한 반응은 "테스트를 작성하라"는 것입니다. 그러나 에이전트 테스트는 결정론적 함수 테스트와 구조적으로 다르며, 여러 가지 문제가 동시에 복합적으로 발생합니다.

• 비결정성. 동일한 구현, 동일한 입력으로도 실행할 때마다 다른 출력을 생성할 수 있습니다. 테스트는 정확한 출력을 주장하는 대신 출력의 속성을 평가해야 합니다.
• 느린 피드백 루프. 단일 에이전트 실행은 수십 분이 걸릴 수 있습니다. 1초 미만의 테스트 스위트가 허용하는 방식으로는 반복할 수 없습니다. 모든 평가 주기는 비용이 많이 듭니다.
• 연쇄 오류. 3단계에서의 잘못된 결정은 7단계에서의 실패를 초래합니다. 증상이 나타날 때쯤이면 근본 원인은 에이전트 실행의 몇 단계 뒤에 묻혀 있습니다.
• 주관적인 품질. 많은 테스트 차원(이 기능 엔지니어링 코드가 좋은가요? 이 데이터 정리 접근 방식이 적절한가요?)에는 정답이 없습니다. 이러한 차원을 판단하는 것은 도메인 전문 지식에 달려 있습니다.

이러한 제약 조건은 이후의 모든 설계 결정에 영향을 미쳤습니다. 또한 이것이 이 문제를 흥미롭게 만드는 이유입니다. 우리는 단순히 테스트 실행기를 구축하는 것이 아니라, "정확성"이 판단에 달려 있는 확률적이고 장기 실행되며 다단계 프로세스를 위한 자동화된 최적화 방법론을 구축하고 있습니다.

접근 방식을 안내하는 비유

만약 눈을 가늘게 뜬다면, 에이전트 개발은 모든 엔지니어가 이미 알고 있는 개발 루프에 깔끔하게 매핑됩니다.

이 비유는 단순히 설명적인 것이 아닙니다. 이것은 우리가 coSTAR라고 부르는 시스템의 실제 아키텍처입니다. coupled 루프 두 개는 Scenario 정의를 테스트 픽스처로 사용하고, Trace 캡처를 테스트 하네스로 사용하고, 심사위원으로 Assess하고, Refine를 빨강-초록 루프로 사용합니다. 각 부분을 살펴보겠습니다.

S - 시나리오 정의

전통적인 테스트에서 테스트 픽스처는 사전 조건을 설정합니다. 데이터베이스를 생성하고, 데이터로 채우고, 환경을 구성합니다. 우리의 등가물은 시나리오 정의입니다. 초기 상태, 사용자 프롬프트 및 예상 결과에 대한 구조화된 설명입니다.

지저분한 데이터셋에 대해 데이터 분석가 에이전트를 테스트하기 위한 단순화된 시나리오는 다음과 같습니다.

각 시나리오는 설정, 입력 및 성공 기준을 한 곳에 묶습니다. 마치 테스트 픽스처와 같습니다. 우리는 다양한 에이전트에 걸쳐 이러한 스위트를 유지 관리하며, 일반적인 경우, 엣지 케이스 및 알려진 과거 실패를 다룹니다. 새로운 실패 모드를 발견함에 따라 스위트는 시간이 지남에 따라 성장합니다. 프로덕션에서 발견하는 모든 버그는 새로운 시나리오가 되며, 프로덕션 버그는 회귀 테스트가 되어야 합니다.

이 구조를 사용하는 이유는 무엇일까요? 에이전트 실행은 비용이 많이 들기 때문입니다. 단일 시나리오는 실행하는 데 몇 분이 걸립니다. 무엇을 테스트할지 신중하게 결정해야 하며, 시나리오 정의는 이식 가능해야 합니다. 즉, 동일한 시나리오를 다른 에이전트 구현 또는 동일한 에이전트의 다른 버전에 대해 실행할 수 있습니다.

T - 추적 캡처

테스트 스위트를 실행하기 위해 각 시나리오의 프롬프트를 테스트 중인 에이전트(AUT)에 보내는 하네스를 사용합니다. 각 실행은 MLflow 추적으로 캡처됩니다. 이는 에이전트가 사용하는 모든 도구 호출, 모든 중간 출력 및 에이전트가 생성하는 모든 아티팩트에 대한 구조화된 로그입니다. 비행 기록계라고 생각하면 됩니다. 에이전트가 수행한 모든 작업을 순서대로 캡처하므로 나중에 실행의 어떤 부분도 검사할 수 있습니다.

주요 아키텍처 결정: 실행과 채점을 분리합니다. 테스트 하네스는 추적을 생성하고, 심사위원(다음 소개할 내용)이 이를 채점합니다. 이들은 별도의 단계입니다. 추적을 영구 저장함으로써 심사위원을 재실행하지 않고 심사위원을 반복할 수 있습니다. 임계값을 조정하나요? 기록된 추적을 몇 초 만에 다시 채점합니다. 새 심사위원을 추가하나요? 수집한 모든 추적에 대해 실행합니다. 심사위원이 잘못되었다고 의심되나요? 녹음과 비교하여 평가하고 오프라인으로 디버그합니다. 비용이 많이 드는 단일 에이전트 실행은 나중에 심사위원 정렬에 사용할 골든 세트의 후보를 포함하여 여러 번 재사용되는 데이터를 생성합니다.

A - 심사위원으로 평가

심사위원은 추적을 기반으로 실행의 속성에 대해 추론합니다. 에이전트가 유효한 코드를 생성했습니까? 출력이 품질 임계값을 충족했습니까? 에이전트가 올바른 프로세스를 따랐습니까? 앞서 언급했듯이 이 평가는 전통적인 단위 테스트와 다릅니다. 에이전트 출력은 비결정적이고 풍부하므로 정확한 출력을 주장하는 것은 사실상 쓸모가 없습니다.

이러한 심사위원을 구현하는 표준 접근 방식은 "LLM-as-a-Judge"입니다. 전체 추적을 모델에 공급하고 점수와 중요하게는 해당 점수에 대한 근거를 요청합니다. 그러나 이것은 전체 프로그램 상태를 단언문에 덤프하는 테스트를 작성하는 것과 같습니다. 비용이 많이 들고, 취약하며, 디버깅하기 어렵습니다. 에이전트의 경우 단일 추적이 수천 줄이 될 수 있습니다. 이를 심사위원의 컨텍스트 창에 넣으면 판단 품질이 저하됩니다.

대신, MLflow의 에이전트 심사위원을 사용합니다. 즉, 추적을 선택적으로 탐색하는 도구를 갖춘 에이전트 자체입니다. 잘 작성된 테스트가 특정 함수를 호출하고 특정 반환 값을 확인하는 것처럼, 에이전트 심사위원은 추적에서 특정 도구를 호출하고 특정 속성을 확인합니다.

다음은 에이전트 전반에 걸쳐 사용한 몇 가지 예제 심사위원입니다.

스킬 호출 심사위원은 추적을 탐색하고 에이전트가 시나리오의 대상이 되는 스킬을 호출했는지 여부를 식별합니다(그렇지 않으면 스킬의 목적이 AUT에 명확하지 않음).

모범 사례 심사위원은 출력이 Databricks 공식 문서에 따라 모범 사례를 따르는지 여부를 탐색합니다.

Outcome Judge은(는) 추적을 검사하여 출력 에셋을 확인하고 특정 속성을 주장합니다. 데이터 분석가 예시로 돌아가서, 엔지니어링 코드가 작성된 추적 부분을 식별하고 해당 코드가 현재 작업에 적합한지 평가합니다.

이 판사는 주관적인 품질 문제를 정면으로 다루기 때문에 흥미롭습니다. 즉, 좋은 특성 엔지니어링이 무엇인지는 도메인 전문 지식에 따라 달라집니다. LLM 판사는 이를 즉시 올바르게 처리할 수 없습니다. 판사의 프롬프트에 전체 기준을 작성해 보려는 유혹이 있을 수 있습니다. "왜도 분포의 경우 평균 대체보다 중앙값 대체 선호, 거리 기반 모델 전에 항상 특성 스케일링, ..." 하지만 도메인 전문가의 전체 판단을 프롬프트로 인코딩하는 것은 노동 집약적이고 취약합니다. 인간이 예시를 보고 "이것은 좋다" 또는 "이것은 나쁘다"라고 말하는 것이 전체 사양을 작성하는 것보다 훨씬 쉽습니다. 이것이 바로 정렬이 작동하는 이유이며, 곧 다룰 것입니다.

일반적으로 단일 에이전트에 대한 테스트 스위트에는 여러 범주에 걸쳐 판사가 포함됩니다.

결정론적 검사, 기계적으로 확인할 수 있는 것, LLM이 필요하지 않음:

• 생성된 코드의 구문/린팅
• 출력 스키마 유효성 검사(예상 테이블이 존재합니까? 열 유형이 올바릅니까?)
• 도구 시퀀스 린팅(에이전트가 문제를 수정하려고 시도하기 전에 오류 로그를 읽었습니까, 아니면 코드를 직접 편집했습니까?)

LLM 기반 검사, 컨텍스트 이해가 필요한 판단:

• 코드 차이 지침(에이전트가 관련 없는 줄을 변경했습니까? 사용 중단된 API를 도입했습니까?)
• 모범 사례 준수(생성된 코드가 이 도메인의 규칙을 따르고 있습니까?)

운영 지표, 개별적으로 통과/실패하지 않지만 시간이 지남에 따라 상태를 추적하는 신호:

• 토큰 사용량(높은 토큰 수는 에이전트가 어려움을 겪고 있거나, 재시도하거나, 방황하고 있음을 나타낼 수 있음)
• 도구 호출 수 및 실패율(실패한 도구 호출 급증은 문제가 있음을 나타냄)
• 지연 시간(에이전트가 작업을 완료하는 데 걸리는 벽 시계 시간)

운영 지표는 참고할 가치가 있습니다. 통과/실패 판사처럼 릴리스를 차단하지는 않지만 비용 관리 및 조기 경고에 중요합니다. 변경 후 토큰 사용량이 두 배가 되면 모든 판사가 여전히 통과하더라도 무언가 잘못된 것입니다. 에이전트가 예상보다 더 많은 작업을 하고 있을 가능성이 높습니다. 시간이 지남에 따라 이러한 지표를 추적하고 이상 징후에 대해 경고합니다.

시간이 지남에 따라 테스트 스위트 확장

테스트 스위트는 한 번에 작성되지 않습니다. 시간이 지남에 따라 발전합니다. 출력물이 존재합니까? 구문 분석이 됩니까?와 같은 가장 간단한 신호를 제공하는 검사로 시작합니다. 그런 다음 구조적 검사가 이어집니다. 출력물이 올바른 스키마, 올바른 열, 올바른 유형을 가지고 있습니까? 나중에야 최종 데이터 유효성 검사 판사가 나옵니다. 출력물이 실제로 올바른 결과를 생성합니까?

이는 전통적인 소프트웨어에서 테스트 스위트가 성숙하는 방식과 유사합니다. 첫날부터 철저한 통합 테스트가 제공되지는 않습니다. 스모크 테스트로 시작하여 실패 모드가 나타남에 따라 단위 테스트를 수행하고 시간이 지남에 따라 최종 커버리지를 구축합니다. 핵심은 인프라가 새로운 판사를 저렴하게 추가할 수 있도록 지원하여 테스트 스위트가 에이전트와 함께 성장한다는 것입니다.

테스트 테스트: 판사 정렬

모든 엔지니어가 아는 문제입니다. 불안정하거나 잘못된 테스트 스위트가 잘못된 코드를 자신 있게 출시합니다. 마찬가지로, 열악한 결과를 승인하는 판사는 잘못된 보안 감각을 제공합니다. 이것이 coSTAR 프레임워크의 두 번째 루프가 들어오는 곳입니다. 에이전트 개선을 주도하는 것과 동일한 시나리오와 추적이 인간 전문가 점수를 기준으로 판사 개선을 주도합니다. 테스트 정확성을 검사하여 확인할 수 있는 전통적인 테스트와 달리 LLM 판사는 확률적이며 자연어 기준 해석 방식이 달라질 수 있으므로 이는 중요합니다. 따라서 이를 확인하고 인간 전문가와 일치시키는 방법이 필요합니다.

이 정렬을 수행하기 위해 먼저 엔지니어가 수동으로 평가한 에이전트 출력의 일반적인 수십 가지 예로 구성된 골든 세트를 큐레이션합니다. 이것이 판사가 동의해야 하는 기준 진실입니다. 그런 다음 MLflow의 정렬 기능(GEPA 및 MemAlign과 같은 기술 기반)을 활용하여 골든 세트에 대해 판사를 자동으로 개선합니다. 이것이 AUT 자체를 개선하기 위해 사용하는 것과 구조적으로 동일한 STAR 루프이지만, 평가 단계는 인간 전문가가 수행하고 개선 단계는 판사에 적용된다는 점에 유의하십시오.

R - 개선

판사 루프가 인간 전문가의 판단에 맞춰 정렬된 판사를 사용하여 이제 에이전트 루프를 신뢰할 수 있습니다. 코딩 도우미는 에이전트를 코드베이스로 취급하고 판사를 테스트 스위트로 취급합니다. 실패를 읽고, 근본 원인을 진단하고, 에이전트를 패치하고, 모든 것을 다시 실행합니다. 엔지니어는 여전히 에이전트에 대한 제안된 변경 사항의 검토자이자 최종 중재자이지만, 이 자동화된 반복은 에이전트를 분석하고 개선하는 데 상당한 인간 노력을 절약합니다.

데이터 분석가 에이전트의 한 가지 반복은 다음과 같습니다.

빨강. 시나리오 스위트에 대해 에이전트의 초기 버전을 실행했습니다. 모범 사례 판사가 불일치를 발견했습니다. 에이전트가 공식 권장 사항/문서와 다른 논리적 뷰에 대한 코드를 생성하고 있었습니다. 이 불일치가 정확성에 영향을 미치지는 않지만 생성된 코드의 유지 관리 및 배포에 영향을 미쳤습니다. 이것은 수동 조사로는 파악하기 어려운 교활한 회귀의 예입니다.

녹색. 코딩 도우미가 판사 피드백을 분석하고 격차를 식별했습니다. 에이전트가 생성해야 하는 뷰 유형(임시 vs 영구)에 대해 명시적이지 않은 기술을 사용하고 있었습니다. 해당 기술에 관련 지침을 추가한 후 테스트가 성공적으로 통과되었으며 변경 사항이 다른 회귀를 도입하지 않았음이 확인되었습니다(다른 테스트 시나리오 기반).

인프라에 대한 회귀 테스트, 에이전트뿐만 아니라

지금까지 판사를 에이전트 테스트로 설명하여 에이전트 구현이 변경될 때 회귀를 포착했습니다. 그러나 실제로는 에이전트 자체가 변경되는 유일한 것이 아닙니다. 에이전트는 외부 도구 및 인프라에 의존하며, 이들도 변경됩니다.

에이전트는 데이터 액세스, 코드 실행, 환경 설정 등을 위한 표준화된 인터페이스인 MCP 도구를 호출합니다. 이러한 도구에는 자체 개발 팀과 릴리스 주기가 있습니다. 도구가 구현을 변경하면(예: 코드 실행 도구가 다른 형식으로 stderr를 반환하기 시작하거나 데이터 액세스 도구가 null 값 처리 방식을 변경하는 경우) 에이전트는 전혀 변경되지 않았지만 에이전트의 동작이 중단될 수 있습니다.

매일 밤 빌드마다 판사를 실행하므로 에이전트의 현재 구현뿐만 아니라 전체 스택에 대한 회귀 테스트 역할을 합니다. 도구 팀이 변경 사항을 출시하여 에이전트가 판사를 실패하기 시작하면 고객에게 도달하기 전에 오류를 즉시 포착합니다. 더 중요한 것은 판사의 실패가 무엇이 잘못되었는지(회귀된 특정 품질 차원)를 알려주므로 에이전트 또는 에이전트가 의존하는 도구의 근본 원인인지 여부를 분류하는 것이 훨씬 쉽다는 것입니다.

이것은 전통적인 소프트웨어에서 통합 테스트가 제공하는 것과 동일한 가치입니다. 코드와 해당 종속성 간의 계약을 보호합니다. 유일한 차이점은 여기서 "코드"가 에이전트이고 "종속성"이 MCP 도구라는 것입니다.

평가에서 프로덕션 모니터링까지

테스트 비유의 또 다른 확장이 놀랍도록 가치 있는 것으로 판명되었습니다. 프로덕션 트래픽에 대해 동일한 판사를 실행하는 것입니다.

전통적인 소프트웨어에서 테스트는 CI에서 끝나지 않습니다. 프로덕션도 모니터링됩니다. 오류율, 지연 시간 백분위수, 실시간 트래픽에 대한 비즈니스 메트릭입니다. 개발에서 코드를 검증하는 것과 동일한 테스트 로직이 프로덕션의 상태 확인 및 경고로 자주 다시 나타납니다.

우리는 동일한 작업을 수행합니다. 평가를 위해 구축한 판사는 평가 시나리오뿐만 아니라 모든 에이전트 대화를 채점하도록 설계되었습니다. 따라서 실제 프로덕션 대화에서 이를 실행합니다(또는 샘플링된 하위 집합). 이를 통해 다음을 얻을 수 있습니다.

• 드리프트에 대한 조기 경고. 프로덕션 대화에서 판사의 통과율이 떨어지면 무언가 변경된 것입니다. 모델 업그레이드로 인해 품질이 저하되었거나 사용자 프롬프트가 에이전트가 제대로 처리하지 못하는 방식으로 변경되었을 수 있습니다. 사용자 불만보다 판사 점수에서 이를 확인합니다.
• 테스트 스위트에 대한 실제 신호. 판사가 실패로 표시한 프로덕션 대화는 새로운 평가 시나리오의 후보가 됩니다. 이것이 테스트 스위트가 유기적으로 성장하는 방식입니다. 실제 실패는 평가로 다시 피드백되어 프로덕션과 개발 간의 루프를 닫습니다.
• 에이전트 수준의 비용 모니터링. 프로덕션 대화에서 토큰 사용량과 도구 호출 수를 추적합니다. 비용을 세 배로 늘리는 품질 중립적인 변경도 회귀입니다.

핵심 인사이트는 동일한 채점 인프라(심사위원, 지표, 기록된 추적)가 이중으로 사용된다는 것입니다. 평가를 위해 한 번 구축하면 프로덕션 모니터링은 부수적인 결과로 제공됩니다.

현재 상황

저희는 Databricks 플랫폼의 여러 에이전트(예: Genie의 데이터 엔지니어링, 머신러닝 및 추적 분석 기능), 개발자 생산성을 위한 내부 에이전트, 그리고 기타 고객 대면 에이전트(예: AI Dev Kit 또는 OSS MLflow Assistant) 전반에 걸쳐 이 방법론을 채택했습니다. 전반적으로 실질적인 이점을 확인했습니다:

• 수동 평가에 비해 자동화된 테스트 스위트는 변경 사항을 확인하는 데 걸리는 시간을 2주에서 몇 시간으로 단축했습니다. 따라서 팀은 더 빠른 속도로 개선 사항을 출시할 수 있었습니다.
• 여러 테스트 스위트가 에이전트당 수백 개의 테스트 시나리오로 확장되어 회귀를 탐지하는 데 대한 확신을 높였습니다.
• 통합 테스트는 종속 인프라의 변경 사항을 표시하여 프로덕션에서 회귀를 방지할 수 있었습니다. 이러한 변경 사항의 예로는 기본 모델의 TODO 관리 동작, 지연 시간에 영향을 미치는 변경 사항 또는 모델 변경 사항이 있습니다.

MLflow는 GenAI 테스트 플랫폼으로서 엔지니어가 방법론을 표준화하고, 테스트 개발을 가속화하며, 팀 간에 모범 사례를 공유하는 데 중요한 역할을 했습니다.

작동하지 않는 것 (아직)

테스트 비유도 여기서 유용합니다. 저희의 한계는 익숙한 테스트 문제에 해당합니다:

시나리오 생성은 수동입니다 (테스트 케이스 작성은 비용이 많이 듭니다). 저희는 채점, 정렬 및 최적화를 자동화했지만 시나리오 자체를 생성하는 것은 여전히 사람의 작업입니다. 각 시나리오는 현실적인 초기 상태, 의미 있는 프롬프트 및 올바른 기대치를 신중하게 구성해야 합니다. 이것이 테스트 스위트 크기를 제한하는 병목 현상이며, 좁은 테스트 스위트는 다음 문제로 직접 이어집니다. 시나리오 생성 자동화(프로덕션 트래픽 패턴 또는 에이전트 사양에서 다양하고 현실적인 테스트 케이스 합성)는 저희에게 중요한 작업 영역입니다.

코딩 도우미가 과적합될 수 있습니다 (테스트 스위트가 너무 좁음). 테스트 스위트가 충분한 사례를 다루지 않으면 코딩 도우미는 특정 입력에 대해 완벽하게 작동하지만 새로운 입력에는 실패하는 에이전트 구현을 엔지니어링합니다. 이것은 프로덕션에서 실패하는 단위 테스트를 통과하는 코드를 작성하는 것과 같은 에이전트입니다. 저희는 프로덕션 실패를 평가에 다시 피드하고 시간이 지남에 따라 적용 범위를 확장하여 이를 완화하지만, 시나리오 생성이 자동화될 때까지 테스트 스위트 확장은 원하는 만큼 빠르지 않습니다.

심사위원 정렬은 비용이 많이 듭니다 (테스트 보정에는 인적 노동이 필요합니다). 골든 세트를 구축하려면 도메인 전문가가 출력을 수동으로 채점해야 하는데, 이는 저희가 제거하려는 정확한 병목 현상입니다. 그리고 이것은 일회성 비용이 아닙니다. 에이전트가 발전함에 따라 심사위원은 재보정이 필요합니다. 저희는 심사위원의 불확실성을 측정하고, 심사위원에게 불분명하고 인간의 레이블이 실제로 모호성을 해결할 수 있는 특정 예제를 식별하여 이를 더 스마트하게 만드는 방법을 조사하고 있습니다. 목표는 심사위원 정렬을 위한 능동 학습입니다. 전문가에게 무작위 샘플을 채점하도록 요청하는 대신, 심사위원에게 불확실한 예제만 표시하고 도메인 전문가의 입력이 기준을 가장 날카롭게 만들 것입니다.

다단계 실패는 속성 분석이 어렵습니다 (근본 원인 분석). 에이전트가 10단계 파이프라인의 7단계에서 실패하면 근본 원인이 7단계에 있었을까요, 아니면 3단계에 있었을까요? 저희 심사위원은 증상을 감지하지만 코딩 도우미는 때때로 잘못된 함수를 변경하여 테스트 실패를 수정하는 것처럼 잘못된 단계를 패치합니다. 더 나은 인과 관계 추적은 현재 진행 중인 작업입니다.

새로운 실패 모드가 간과됩니다 (적용 범위 격차). coSTAR는 심사위원이 다루는 차원 내에서 최적화됩니다. 어떤 심사위원도 확인하지 않는 새로운 유형의 실패가 나타나면, 어떤 테스트도 실행하지 않는 코드의 버그처럼 보이지 않습니다. coSTAR는 테스트 스위트 *내에서* 개선되지만, 테스트 스위트를 자체적으로 확장할 수는 없습니다. 사람은 여전히 새로운 실패 모드를 인지하고 심사위원을 추가해야 합니다.

주요 내용

1. 에이전트 개발에는 테스트 문제가 있습니다. 자동화된 평가 없이는 테스트 없이 코딩하는 것이며, 당연히 회귀가 발생할 것입니다.
2. 심사위원에게 추적이 아닌 도구를 제공하십시오. 대상 도구를 호출하는 에이전트 심사위원은 집중된 단위 테스트와 같습니다. 전체 추적을 심사위원에게 전달하는 것은 단언에 프로그램 상태를 전달하는 것과 같습니다. 확장성이 없습니다.
3. 테스트를 테스트하십시오. LLM 심사위원은 확률적입니다. 사양에 대해 테스트 스위트를 검증하는 것과 같은 방식으로 인간이 채점한 골든 세트에 대해 정렬하십시오.
4. 루프를 닫으십시오. 진정한 승리는 전체 coSTAR 루프입니다. 신뢰할 수 있는 시나리오, 기록된 추적, 정렬된 심사위원, 그리고 테스트를 통과할 때까지 에이전트를 개선하는 코딩 도우미입니다. 자동화된 개선 없이는 평가가 절반에 불과합니다.
5. 한 번 구축하고 어디서나 모니터링하십시오. 평가에서 검증하는 동일한 심사위원이 프로덕션을 모니터링할 수 있습니다. 하나의 투자, 두 개의 수익.
6. 커플링이 중요합니다. 에이전트를 개선하는 것은 이를 구동하는 심사위원만큼만 신뢰할 수 있습니다. 심사위원의 신뢰를 얻는 루프와 그 신뢰를 사용하여 에이전트를 개선하는 루프라는 coSTAR의 두 가지 커플링된 루프는 자동화된 개선을 단순히 빠른 것이 아니라 의미 있게 만드는 것입니다.

저희는 MLflow의 일부로 coSTAR를 구축하고 있습니다. 비슷한 문제를 해결하고 있다면 저희에게 알려주시면 감사하겠습니다.

• coSTAR 방법론을 사용하여 출시한 기능을 보려면 Genie Code를 사용해 보세요.
• 반복적인 에이전트 개선을 위해 LLM 심사위원을 정의하고 사용하는 방법을 시작하려면 MLflow의 튜토리얼을 따르세요.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)