심층 해설 · 약 5분 읽기
Perplexity 에이전트 평가 가이드: 실행 기록과 보정된 채점자로 점수를 해석한다
공식 6단계 가이드는 실제 실패, 고정 테스트 데이터, 전문가 판단으로 보정한 채점자를 연결한다. 한 번의 정답으로 신뢰성을 입증할 수는 없다.
- 사이트 게시일
- 원문 게시일
- 출처 확인일
Perplexity가 10월 22일 공개한 글은 에이전트 평가를 설계하는 방법 안내다. 새 모델 출시나 새로운 벤치마크 결과 발표가 아니다. 부품 구매 사례는 점수를 해석하기 전에 행동, 반복 가능성, 채점의 품질을 알아야 하는 이유를 보여 준다.
뉴스 듣기
이 기사를 읽어 드리거나 뉴스를 계속 재생합니다.
읽기를 준비하는 중…
기기 음성
읽기는 브라우저나 기기에서 처리합니다. AISubHub는 내용을 오디오 API로 보내지 않습니다. 사용 가능한 음성과 잠금 화면 재생은 기기에 따라 다릅니다.
계속 재생할 때 짧은 구절이 반복될 수 있습니다.
핵심 요약
- 그럴듯한 최종 답변 뒤에 무단 행동이나 유출된 정답 사용이 숨을 수 있으므로 결과와 경로를 모두 확인한다.
- 약 100개 실행 기록은 오류 분석의 참고치이지 의무 기준이 아니다. pass@k는 명시한 k번 중 최소 한 번 성공한다는 뜻이다.
- 동일한 저장 실행을 반복 채점해야 채점자 변동을 분리한다. 회귀 검사, 운영 모니터링, A/B는 역할이 다르다.
정답 뒤에 무엇이 숨을 수 있나
재고 도우미는 겉으로 적절한 부품을 추천하면서 승인 규칙을 건너뛸 수 있다. Perplexity의 공장 사례에서 승인 부품이 없거나 공급업체 정보가 낡았다면 적절히 대응해야지, 근거 없는 대체품을 추천해서는 안 된다. 가이드는 업무 성공 조건과 성공처럼 보여도 허용할 수 없는 수행 방식을 함께 정의하고 분야 전문가에게 실제 업무와 맞는지 확인하도록 한다. 유창한 답변은 권한 준수의 증거가 아니다.
평가에는 검색한 정보, 도구 호출, 중간 결정도 포함된다. 과업 성공, 행동의 정확성, 답변 품질은 서로 다른 속성이며 신뢰성은 반복 시도와 경계 사례에도 관련된다. 시간, token, 도구 호출은 성공한 과업의 비용에 영향을 준다. 본 사이트 분석: 배포 판단에는 잘 쓴 답변에 대한 선호가 아니라 전체 업무 흐름을 대상으로 한 명확한 인수 조건이 필요하다.
어떤 실패를 테스트에 넣어야 하나
가이드는 입력, 검색 근거, 행동, 출력을 담은 실제 실행 기록에서 출발한다. 전문가가 각 실행의 첫 의미 있는 오류를 기록한 뒤 비슷한 관찰을 실패 유형으로 묶는다. LLM이 분류를 제안할 수 있지만 우선순위는 빈도와 심각성을 함께 고려한다. 중요한 실패는 입력, 시작 조건, 기대 결과, 채점 기준을 갖춘 재사용 사례가 된다. 고칠 문제를 통과하기 쉬운 합성 과제로 바꾸지 않기 위해서다.
약 100개 기록은 실무적 참고치이지 보편적 표본 요건이나 통계적 신뢰 보장이 아니다. 추가 기록이 의미 있는 새 실패 양상을 더 이상 드러내지 않는 이론적 포화에 도달하면 일찍 중단할 수 있다. 출시 전에는 합성 사례로 시작하되 실제 사용자 데이터가 생기면 반영해야 한다. 표준 벤치마크는 보완 수단이며 뜻밖의 합격이나 실패는 문제와 정답 기준을 먼저 조사해야 한다.
두 버전에 같은 문제를 주려면
그림은 저장한 정비 요청과 고정 재고·승인 부품 데이터를 분리한다. maintenance_request_01.json은 입력과 기대 결과, inventory_snapshot.json과 approved_parts.json은 비교용 데이터를 담는다. run_evals.py는 흐름을 실행·검사하고 results는 출력, 실행 기록, 합격·실패 판정을 저장한다. 이는 구성 예시이지 본 사이트가 실행한 운영 시스템이나 소프트웨어 패키지가 아니다. 본 사이트 분석: 비교 중 재고가 바뀌면 에이전트뿐 아니라 문제도 달라진다.
최종 문장 외에 검색 단계와 도구 행동도 보존해야 한다. 같은 입력에서도 결과가 달라질 수 있으므로 위험도, 빈도, 수정 난도에 따라 반복한다. pass@1은 단일 시도의 성공을, pass@k는 지정한 k번 중 적어도 한 번의 성공을 나타낸다. k를 반드시 명시해야 한다. 여러 답변 중 정답 하나를 찾았다고 매번 성공하거나 에이전트가 그 정답을 고를 줄 안다는 뜻은 아니다.
각 요구사항은 누가 판정하나
정확히 검증할 수 있는 조건에는 코드 기반 검사를 권한다. 승인 부품 여부, 유효한 필드, 올바른 도구 인수, 예상한 데이터베이스 최종 상태 등이 해당한다. 규칙은 명확하지만 모든 주관적 판단을 안정적으로 해결하지는 못한다. 대체품 추천을 거절한 설명이 적절한지처럼 맥락이 필요한 문제에는 명시적 평가 기준을 갖춘 LLM을 쓸 수 있다. 기준은 허용 행동과 판정 근거를 규정해야 한다.
전문적이거나 논쟁적인 결정에는 여전히 전문가가 필요하다. 한 실행의 여러 검사에 다른 채점자를 조합할 수 있으며, 플랫폼을 선택했다고 사업에 중요한 실패가 정해지는 것은 아니다. 본 사이트 분석: 권한 검사와 설명 품질을 나누면 종합 점수의 의미가 명확해진다. LLM의 문장 호평이 승인 목록의 정확한 대조를 몰래 대체해서는 안 된다. 이 분업에 따른 정확도 개선 수치는 원문에 없다.
에이전트 오류와 채점자 오류를 어떻게 구분하나
가이드의 보정은 다섯 단계다. 입력·출력·기록 수집, 전문가의 독립 판단, LLM 채점, 양쪽 결정 비교, 불일치 조사와 기준 수정 후 새 사례 검증이다. 이 과정에서 인간 판단은 참조 기준이며 무오류라는 주장이 아니다. 보정은 평가자를 평가하는 일이지 시험 중인 에이전트를 다시 실행하는 일이 아니다.
채점 일관성을 확인하려면 에이전트를 재실행하지 않고 정확히 같은 저장 실행과 파일을 여러 번 채점해야 한다. 그렇지 않으면 두 변동이 섞인다. 혼동 행렬은 찾아낸 오류, 놓친 오류, 적절한 출력을 잘못 실패로 표시한 경우를 살핀다. 수동 검토는 기존 채점자가 모르는 실패 유형도 발견한다. 원문에 연결된 벤치마크 연구는 본 사이트가 독립적으로 전문을 읽거나 결과를 재현하지 않았다.
수정 하나로 언제 배포할 수 있나
저장 입력으로 원래 실패를 재현하고 프롬프트·모델·흐름을 한정해 수정한 뒤 해당 사례가 해결됐는지 확인한다. 이어 나머지 테스트 전체를 실행해 예전에는 성공했던 행동이 망가지지 않았는지 본다. 기준 버전과 새 버전은 같은 사례와 채점 기준을 써야 한다. 단언문, 테스트 프레임워크, CI/CD로 검사와 배포 임계값을 자동화할 수 있지만 기준이 실제 제품 위험을 포괄한다는 증명은 아니다.
배포 뒤에는 보정한 채점자로 운영 기록을 표본 검사하고 실패 유형을 추적하며 사람이 특이 요청과 새 오류를 살핀다. 적절한 A/B는 해결률이나 만족도 같은 사업 근거를 더하지만 평가를 대체하거나 모든 원인을 설명하지 않는다. 본 사이트 분석: 관찰한 실패, 반복 가능한 검사, 회귀 판단을 연결하는 순환이 핵심이다. 이 방법 안내는 새로운 이용 권리나 독립 측정한 신뢰성을 입증하지 않는다.
중요한 이유
실패, 근거, 채점자를 보존하면 에이전트 수정을 검증할 수 있다. 전체 흐름과 비교한 뒤 실제 사용에서 얻은 정보를 반영하는 데 도움이 된다.
제한 및 이용 가능성
Perplexity의 방법 안내와 구매 예시를 다룬 글이다. 본문과 구성 그림을 읽었으나 외부 연구, 운영 에이전트, 계정 권한은 검증하지 않았다. 정확도, 비용 절감, 보편적 통과 기준도 실측하지 않았다.
출처와 근거
AI 보조 편집 기사를 명시한 일차 출처와 대조합니다. 업체 주장은 출처를 밝히며 게재는 추천을 뜻하지 않습니다.