평가 주도 개발 (Eval-driven development)

Airbnb는 비결정적 출력과 주관적 정답, 검색·추론·도구 호출의 연쇄 실패를 다루기 위해 평가를 사후 검증이 아닌 핵심 엔지니어링 규율로 취급함 평가 주도 개발(EDD) 은 실제 오류를 발견해 평가 기준으로 만들고 지속적으로 검사하며, 출시 목표와 게이트를 먼저 정하고 최종 인간 의사결정자를 둠 결정론적 검사, LLM 심판(LLM-as-a-Judge), 인간 평가를 계층적으로 사용하며, 가상 심판은 나쁜 사례를 포함한 50~100개 골든 데이터셋에서 인간과 80% 후반~90%대 일치하도록 보정해야 함 에이전트 시스템은 최종 답변만으로 평가할 수 없으므로 실행 추적과 스팬을 재구성해 하위 에이전트 호출 시점, 도구 선택, 매개변수와 중간 상태까지 검사해야 함 프로덕션에서도 비식별화된 실사용 트래픽을 지속적으로 표본 추출하고 새 실패 유형을 평가에 반영해야 하며, 좋은 모델보다 명확한 제품 기준과 팀 협업이 성공을 좌우함 GenAI 평가가 기존 테스트와 다른 이유 LLM 출력은 비결정적이고 무엇이 올바른지에 대한 판단도 주관적이어서 전통적인 소프트웨어 테스트의 가정이 그대로 적용되지 않음 AI가 다른 AI를 평가해야 하는 경우가 많지만, 평가 모델 자체에도 별도의 실패 가능성이 있음 한 번의 LLM 상호작용이 검색, 추론, 도구 호출, 생성으로 이어질 수 있으며 각 단계가 독립적으로 실패할 수 있음 Airbnb는 리뷰 하이라이트, AI 고객 지원, 게스트·호스트용 스마트 커뮤니케이션 기능 등에 LLM을 사용하고, 제품 동향과 개선 지점을 파악하는 데도 AI를 활용함 제품 팀마다 기준과 절차, 워크플로가 다르지만 공통 기반과 원칙은 인프라 팀이 도구와 모범 사례로 제공함 평가 방법에는 단일 정답이 없으므로 제안 사항을 모든 제품에 일률적으로 적용해서는 안 됨 평가를 처음부터 계획해야 하는 이유 의도적인 평가 전략이 없으면 세 가지 문제가 발생하기 쉬움 일반적인 유용성 점수만 높고 실제 사용자가 겪는 실패는 잡지 못해 잘못된 확신을 얻음 측정하지 않은 품질 차원이 프롬프트 변경으로 악화돼 회귀를 발견하지 못함 실제 결과와 상관없는 지표를 위해 대규모 평가 파이프라인을 구축해 노력을 낭비함 전체 프로젝트에서 상당한 비중을 평가에 배정해야 하며, 이는 불필요한 부가 작업이 아니라 실제로 작동하는 제품을 만드는 과정임 가장 먼저 데이터를 직접 읽기 프로토타입에 합성 데이터를 포함한 100개 예제를 실행한 뒤 출력과 실행...