소개

AI 앱을 새로 만들거나 기존 앱을 수정할 때는 앱이 예상대로 동작하는지 확인해야 합니다. 평가를 통해 여러 시나리오를 체계적으로 테스트하고 변경 사항을 배포하기 전에 회귀 문제를 찾아낼 수 있습니다.

Promptfoo로 AI 앱 평가를 실행하고, Codex의 도움을 받아 평가를 작성하고 관리할 수 있습니다.

사용 방법

Codex에서 Promptfoo 플러그인의 $promptfoo-evals 스킬을 사용해 AI 앱의 특정 동작을 반복해서 검증할 평가 스위트를 만드세요. Promptfoo에서 앱을 호출할 평가 대상이 아직 설정되어 있지 않거나 제대로 작동하지 않으면 $promptfoo-provider-setup 스킬로 스위트를 테스트하려는 앱 경로에 연결할 수 있습니다.

Codex는 앱을 살펴보고 문제를 잘 드러내는 테스트 케이스를 제안할 수 있습니다. 또한 Promptfoo 설정과 테스트 데이터를 추가하고, 로컬에서 스위트를 실행한 뒤, 이후에도 같은 평가를 실행할 수 있는 명령어를 제공합니다.

이 방식은 평가할 동작이 구체적일 때 가장 효과적입니다. 예를 들어 고객 지원 답변의 품질, 검색 결과를 바탕으로 한 그라운딩, 분류기가 반환하는 레이블, 도구 호출, JSON 구조, 비즈니스 규칙 준수 여부를 평가할 수 있습니다. 프롬프트나 모델을 교체해도 기대한 동작이 유지되는지 확인하는 데도 적합합니다.

첫 구현의 결과물은 검토할 수 있는 코드와 테스트 데이터여야 합니다. promptfooconfig.yaml 또는 이에 해당하는 설정 파일, 작은 evals/ 디렉터리, 테스트 케이스를 준비하세요. 앱 호출에 필요한 경우 평가 대상 어댑터를 추가하고, npm run evals와 같은 로컬 실행 명령어도 포함하세요.

평가 대상 선택하기

앱이 사용자에게 보장해야 하는 동작 하나부터 시작하세요. Codex에 AI 시스템 전체를 한 번에 평가해 달라고 요청하지 마세요. 스위트가 작으면 내용을 검토하고 결과를 신뢰하기 쉬우며, 평가를 꾸준히 실행하기도 쉽습니다.

처음 평가할 대상으로는 다음과 같은 항목이 적합합니다.

• 정확성: 분류, 추출, 요약, 라우팅 또는 변환 결과가 올바른지 확인합니다.
• 그라운딩: 답변이 검색된 문서나 인용한 출처에 근거하는지 확인합니다.
• 도구 사용: 적절한 도구를 선택하고, 유효한 인수를 전달하며, 도구 오류를 처리하는지 확인합니다.
• 형식 또는 비즈니스 규칙: JSON 스키마, 필드 이름, 비즈니스 규칙에서 정한 한도, UI에 표시할 문구에 관한 요구 사항을 지키는지 확인합니다.
• 프롬프트 또는 모델 마이그레이션: 새 프롬프트, 모델, 시스템 메시지 또는 검색 설정을 적용해도 중요한 케이스가 계속 통과하는지 확인합니다.

제품 요구 사항, 버그 보고서, 상위 지원팀으로 이관된 문의 또는 민감한 정보를 제거해 팀에서 레포지토리에 커밋해도 좋다고 판단한 예시를 바탕으로 시작하세요.

평가 계획 요청하기

Codex가 파일을 수정하기 전에 먼저 앱을 살펴보도록 하세요. 평가 대상 경로, 픽스처, 검증 조건, 어댑터, 명령어를 명시한 계획을 요청하세요. 그러면 파일을 추가하기 전에 평가 대상이 잘못되었는지, 테스트 케이스가 의도한 동작을 충분히 검증하는지 확인할 수 있습니다.

구현에 들어가기 전에 계획을 검토하세요. 계획에는 Promptfoo가 호출할 앱 경로나 엔드포인트, 처음 사용할 테스트 케이스, 검증 조건, Codex가 만들 파일, 로컬 실행 명령어, 필요한 시크릿이나 서비스가 명시되어 있어야 합니다. 사용자가 실제로 이용하는 앱 경로를 거치지 않고 모델을 직접 테스트하는 계획이라면 의도한 것인지 Codex에 물어보세요.

구현하고 실행하며 개선하기

계획이 적절한지 확인했다면 Codex에 구현을 요청하세요. 첫 구현은 단순하게 유지하세요. 설정, 테스트 케이스, 픽스처, 필요한 경우 평가 대상 어댑터, 실행 명령어를 갖추고 명령어를 실제로 실행한 결과를 확인할 수 있으면 됩니다.

실제 앱을 호출하는 작은 스위트는 다음과 같이 구성할 수 있습니다.

evals/
  promptfooconfig.yaml
  tests/
    cases.yaml
  providers/
    provider.js  # only if the built-in provider cannot call the app directly

앱 동작을 변경하기 전에 스위트를 실행하세요. 이때 얻은 기준 결과를 보면 현재 앱에서도 실패하는 케이스가 있는지, 검증 조건을 조정해야 하는지, 평가 대상 어댑터에 문제가 있는지 판단할 수 있습니다. 검증 조건이 사소한 변화에도 쉽게 실패하거나 너무 모호하면 조정하되, 실제 제품 문제가 가려지지 않도록 하세요.

첫 실행 이후에는 스위트를 사용해 배포 전에 앱 변경 전후의 결과를 비교하세요. 버그, 출시 요구 사항, 제품 검토를 통해 일관되게 유지해야 할 동작을 발견할 때마다 테스트 케이스를 추가하세요. 로컬 실행 명령어가 안정적으로 작동하면 Codex에 이 명령어를 CI나 릴리스 체크리스트에 추가해 달라고 요청하세요.