• Airbnb는 비결정적 출력과 주관적 정답, 검색·추론·도구 호출의 연쇄 실패를 다루기 위해 평가를 사후 검증이 아닌
  핵심 엔지니어링 규율로 취급함
  평가 주도 개발(EDD) 은 실제 오류를 발견해 평가 기준으로 만들고 지속적으로 검사하며, 출시 목표와 게이트를 먼저 정하고 최종 인간 의사결정자를 둠
• 결정론적 검사,
  LLM 심판(LLM-as-a-Judge), 인간 평가를 계층적으로 사용하며, 가상 심판은 나쁜 사례를 포함한 50100개 골든 데이터셋에서 인간과 80% 후반90%대 일치하도록 보정해야 함
• 에이전트 시스템은 최종 답변만으로 평가할 수 없으므로
  실행 추적과 스팬을 재구성해 하위 에이전트 호출 시점, 도구 선택, 매개변수와 중간 상태까지 검사해야 함
• 프로덕션에서도 비식별화된 실사용 트래픽을 지속적으로 표본 추출하고 새 실패 유형을 평가에 반영해야 하며, 좋은 모델보다
  명확한 제품 기준과 팀 협업이 성공을 좌우함

GenAI 평가가 기존 테스트와 다른 이유

• LLM 출력은
  비결정적이고 무엇이 올바른지에 대한 판단도 주관적이어서 전통적인 소프트웨어 테스트의 가정이 그대로 적용되지 않음
• AI가 다른 AI를 평가해야 하는 경우가 많지만, 평가 모델 자체에도 별도의 실패 가능성이 있음
• 한 번의 LLM 상호작용이 검색, 추론, 도구 호출, 생성으로 이어질 수 있으며 각 단계가 독립적으로 실패할 수 있음
• Airbnb는 리뷰 하이라이트, AI 고객 지원, 게스트·호스트용 스마트 커뮤니케이션 기능 등에 LLM을 사용하고, 제품 동향과 개선 지점을 파악하는 데도 AI를 활용함
• 제품 팀마다 기준과 절차, 워크플로가 다르지만 공통 기반과 원칙은 인프라 팀이 도구와 모범 사례로 제공함
• 평가 방법에는
  단일 정답이 없으므로 제안 사항을 모든 제품에 일률적으로 적용해서는 안 됨

평가를 처음부터 계획해야 하는 이유

• 의도적인 평가 전략이 없으면 세 가지 문제가 발생하기 쉬움

• 일반적인 유용성 점수만 높고 실제 사용자가 겪는 실패는 잡지 못해
  잘못된 확신을 얻음

• 측정하지 않은 품질 차원이 프롬프트 변경으로 악화돼 회귀를 발견하지 못함

• 실제 결과와 상관없는 지표를 위해 대규모 평가 파이프라인을 구축해 노력을 낭비함

• 전체 프로젝트에서 상당한 비중을 평가에 배정해야 하며, 이는 불필요한 부가 작업이 아니라 실제로 작동하는 제품을 만드는 과정임

가장 먼저 데이터를 직접 읽기

• 프로토타입에 합성 데이터를 포함한
  100개 예제를 실행한 뒤 출력과 실행 추적을 직접 읽는 것이 출발점임
• 모델의 오류를 찾아 유형별로 분류하고, 관찰된 실패를 평가 항목으로 만들어야 함
• 데이터에서 성공 기준에 대한 직관을 쌓는 습관이 특정 프레임워크나 도구, 방법론보다 제품 품질에 더 크게 기여함

평가 주도 개발의 다섯 원칙

평가 주도 개발(EDD) 은 모든 실패를 미리 예측하는 대신, 나타나는 실패를 발견하고 명문화하며 지속적으로 검사하는 인프라와 습관을 구축하는 GenAI판 테스트 주도 개발임

• 이해관계자가 무엇을 좋은 결과로 볼지 명시하게 만들어 제품 로드맵에도 영향을 줌

• 다섯 가지 원칙이 EDD의 기반을 이룸
  목표와 출시 게이트를 사전에 정의하고 무엇을 최적화하며 출시 전에 어떤 조건을 충족해야 하는지 정함

• 답을 처음부터 알 수 없다면 데이터 탐색 과정에서 발견할 수 있음

• 실제로 관찰한 오류를 바탕으로 여러 직군의 파트너와 지표를 공동 개발하며, 현실과 분리된 지표를 만들지 않음

• 2030개의 잡음 많은 평가기보다 특정 정확성 차원 하나씩을 겨냥한
  **35개의 잘 보정된 평가기**를 유지함

• 올바른 동작에 대한 팀 내 의견이 갈릴 때 최종 판단을 내릴 인간 의사결정자를 지정함

• 제품 파트너가 “X와 Y 중 무엇이 더 나은가”, “이 출력에서 실제로 잘못된 것은 무엇인가”에 지속적으로 답하도록 협업함

세 가지 평가 방법

결정론적 검사

• LLM 호출이 필요 없는 코드 기반의
  프로그램 검사와 휴리스틱을 첫 번째 필터로 삼아 명백한 실패를 먼저 제거함

• JSON Schema 같은 구조화 출력을 사용해 엄격한 타입을 보장해야 함

• 데이터 형식을 프롬프트 지시만으로 강제하면 하위 데이터 파이프라인이 깨질 수 있음

LLM 심판

• 더 강한 LLM이 세밀하게 설계된 루브릭에 따라 다른 LLM의 출력을 평가함

• 인간 평가보다 적은 자원으로 어조, 일관성,
  충실성, 관련성 같은 미묘한 품질을 검사할 수 있음

• 모호한 기준은 피해야 하며, 사람이 일관되게 적용할 수 없는 루브릭은 LLM도 일관되게 적용하기 어려움

• 읽기 쉬움 평가에서는 친근한 여행 상담원처럼 따뜻하지만 전문적이고, 단순하며 자연스럽고 문법적으로 완결된 문장을 통과시킴

• 지나치게 격식적이거나 전문 용어가 많고, 과도하게 가볍거나 판매 지향적이거나 기계적인 어조는 실패 처리함

• 내부 용어, 따옴표, 불릿, 문장 파편을 금지하고 마침표로 끝나게 함

• 자연스러운 관사·한정사·전치사와 쉬운 단어를 요구함

• 오류 유형과 이유, 0 또는 1의 점수만 담은 정해진 JSON 형식으로 반환하게 함

가상 심판 보정

• 보정하지 않은 가상 심판은
  잘못된 확신을 주므로 심판이 없는 것보다 나쁠 수 있음

• 나쁜 사례를 반드시 포함한 50~100개 예제로 골든 데이터셋을 구축함

• 가상 심판을 골든 데이터셋에 실행하고 인간 레이블과의 일치도를 측정함

• 목표는
  80% 후반~90%대이며 Cohen’s kappa 또는 Krippendorff’s alpha로 불일치를 측정할 수 있음

• 인간끼리도 의견이 다르므로 완전한 일치는 달성하기 어려움

• 불일치를 분석해 프롬프트와 퓨샷 예제를 수정하고 목표 일치도에 도달할 때까지 반복함

• 실패 유형이 변하면 정기적으로 다시 보정해야 함

인간 평가

• 인간 판단은 정답 데이터 구축,
  고위험 영역, 자동 평가기 간 불일치 해결에서 기준 역할을 유지함
• 먼저 도메인 전문가가 레이블한 20~100개 행으로 시작하고, 루브릭이 충분히 안정됐으며 처리량만 병목일 때 대규모 주석 인력으로 확장함
• 전문가들이 레이블에 합의하지 못하면 자동화를 중단하고
  인간의 불일치부터 해결해야 함

에이전트 시스템 평가

• 에이전트는 다단계 추론, 도구 호출, 분기 로직과 중간 상태 전이를 포함하므로 최종 출력만 평가해서는 부족함
• 올바른 최종 답변도 잘못된 추론 경로, 부정확한 도구 매개변수 또는 비효율적인 실행 경로를 감출 수 있음
• 애플리케이션 루트 아래 기록되는
  실행 추적과 스팬에는 에이전트 유형, 호출된 하위 에이전트, 입출력, 사용한 도구 등의 정보가 들어 있음
• 실행 추적을 관측 가능성 플랫폼이나 영구 저장소에 기록하고, 깊이 우선 탐색(DFS) 같은 트리 순회로 메모리에서 재구성함
• 재구성된 경로를 통해 적절한 시점에 특정 하위 에이전트가 실행됐는지, 올바른 도구가 호출됐는지 검사하고 평가 범위를 개별 에이전트나 하위 에이전트로 제한할 수 있음

지원 정책 AI 어시스턴트 적용 예시

1단계: 오류 탐색

• 여행 플랫폼의 지원 정책 질문에 답하는 AI 어시스턴트 프로토타입에
  100개 입력을 실행하고 모든 출력을 읽음

• 발견한 오류는 출처에 없는 정책 정보를 생성한 답변 15개, 정확하지만 지나치게 긴 답변 8개, 유효한 질문을 거부한 답변 5개, 깨진 JSON 3개임

• 각각 충실성, 간결성, 과잉 거부, 형식 문제로 분류함

2단계: 평가기 구축

• JSON 유효성과 길이 제한은 프로그램 검사로 처리함

• 충실성 평가기는 별도 프롬프트, 다른 모델, 연쇄적 사고를 사용해 만들고 간결성 평가기도 별도로 구성함

• PM 또는 도메인 전문가가 실패 사례를 포함한
  60개 예제에 레이블을 붙여 골든 데이터셋을 만듦

3단계: 보정과 반복

• 최초 충실성 가상 심판은 PM과
  78% 만 일치해 기준에 미달함

• 심판이 정확한 바꿔쓰기도 충실하지 않다고 감점한 것이 원인이어서 루브릭을 수정하고 퓨샷 예제를 추가함

• 변경 후 일치도가
  88% 로 상승했으며, 검색 단계를 개선하자 충실성 실패가 크게 줄어듦

• 모델과 프롬프트를 반복 개선할 때는 한 번에 변수 하나만 바꿈

• 모델을 고정하고 프롬프트를 변경함

• 프롬프트를 고정하고 모델을 변경함

• 둘을 고정하고 서빙 설정을 변경함

• 각 단계에서 가상 심판 결과로 후보를 좁힌 뒤 상위 후보의 샘플로 심판도 개선하며, 평가기와 후보가 서로 정교해질 때까지 반복함

4단계: 확장과 프로덕션 감시

• 평가를
  5,000개 예제로 확장함
• 매일 비식별화된 실사용 트래픽의 5%를 표본 추출해 프로그램 검사와 가상 심판을 실행하고, 문제가 표시된 출력을 인간 검토로 보냄
• 실사용 트래픽 표본 추출에는 개인정보 보호 기법을 적용하며, 인간 검토 전 데이터를 강하게 비식별화함
• PM이 매주 결과를 검토하고 새 실패 유형을 새로운 평가 항목과 시스템 개선으로 연결함
• 데이터 사용 목적은 Airbnb Privacy Principles에 맞춰
  안전과 품질 보증으로 엄격히 제한함

프로덕션까지 이어지는 운영 원칙

• 제품의 실제 실패 유형을 겨냥한 평가기를 만들고 일반적인 지표에 의존하지 않음
• 각 평가기는 품질 차원 하나만 담당하게 하며 모든 것을 판단하는 단일 평가기를 두지 않음
• 프로그램 검사, 가상 심판, 인간 평가를
  계층적 방어선으로 함께 사용함
• 골든 데이터셋에 나쁜 사례를 넣어 평가기가 좋은 결과와 나쁜 결과를 구별할 수 있는지 확인함
• 모델만이 아니라 검색, 도구 호출과 전체 파이프라인을 평가하고, 에이전트에서는 최종 답변뿐 아니라 실행 경로도 검사함
• 출시 전 평가는 일회성 작업이 아니므로 같은 평가를 프로덕션에서도 지속함
• 제품 성공의 기준을 정하려면 여러 역할의 기여가 필요하며, AI 제품의 성과는 최고의 모델만이 아니라
  원활한 소통과 명확한 제품 비전에 달려 있음

댓글과 토론