고정 프롬프트 기반 평가 파이프라인평가 사례와 도구 명세를 입력과 정답으로 바꾸고 모델 예측을 파일로 기록한 뒤 grader로 비교한다. 도구의 실제 실행과 최종 환경 상태 확인은 이 경로에 포함되지 않는다. 고정 입력에서 모델 예측을 비교하는 평가 준비 → 추론 → 기록 → 채점 평가 사례 · 도구 명세발화 / 대화 문맥 / 기대 계획사용 가능한 함수 정보 평가 예제 구성입력 상태 구성문맥과 함수 정보를 프롬프트로 변환 평가 예제입력 + 정답평가 대상의 종류 모델 추론고정 입력 → 모델 예측모델 상태 / 추론 설정 추론 기록입력 / 정답 / 모델 예측후속 채점과 오류 분석에 활용 채점기함수·파라미터 등 비교정오답 / 오류 정보 이 경로 밖의 질문 도구가 실제로 실행되었는가?환경이 바뀌고 사용자의 목표에 도달했는가?

그림 1. 평가 사례를 입력·정답 쌍으로 바꾸고 모델 예측을 기록한 뒤 채점하는 구조. 실제 업무 도구 실행과 최종 환경 상태 검증은 이 경로의 바깥에 있다.

고정 프롬프트 기반 평가는 미리 준비한 입력을 모델에 주고, 생성한 출력을 기대 결과와 비교하는 방법이다. 같은 조건에서 모델이나 프롬프트를 바꿔 보며 도구 선택과 인자가 올바른지 확인할 때 유용하다.

  • 예시 요청: “10분 타이머 하나 만들어 줘.”
  • 모델이 만들 계획(plan): 타이머 생성 도구를 선택하고, 지속시간을 10분으로 지정하는 행동 명세.
  • 평가 질문: 주어진 문맥에서 올바른 도구와 인자를 생성했는가?
  • 별도로 확인할 질문: 도구를 실행한 뒤 타이머가 실제로 하나만 만들어졌는가?

여기서 plan은 모델이 생성한 실행 계획을 뜻한다. 함수 호출 하나일 수도 있고, 여러 도구를 순서대로 호출하는 계획일 수도 있다. 이 글은 그 계획을 고정된 입력에서 비교하는 평가의 구조와 활용 범위를 설명한다.

  • 읽는 순서: 구성 요소 → 평가 흐름 → 채점 → 정답 이력 활용 → 한계와 적용 기준.
  • 그림 읽기: 모바일에서는 그림을 누르고 100%를 선택하면 본문 크기로 읽을 수 있다.

무엇을 준비하고 무엇을 비교하나

발화·문맥·사용 가능한 도구 정보를 입력으로 준비하고, 모델이 만든 계획을 기대 결과와 비교한다.

구성 요소 의미와 역할
평가 사례(Test case, TC) 사용자 요청, 이전 대화, 기대 결과를 묶은 하나의 사례
입력 상태 이전 대화와 요청이 가리키는 대상 등 모델의 판단에 필요한 정보
도구 명세(Schema) 사용할 수 있는 도구의 이름, 인자와 사용 규칙
프롬프트(Prompt) 요청·문맥·도구 정보를 모델에 전달하는 입력
기대 결과(Ground truth) 해당 입력에서 올바르다고 정한 출력이나 호출 구조
채점기(Grader) 실제 출력과 기대 결과를 비교해 통과 여부와 오류를 판정하는 규칙
  • 평가 준비: 사례별로 모델 입력과 기대 출력을 구성.
  • 추론과 기록: 준비된 입력으로 모델을 호출하고 예측 결과를 후속 채점에 전달.
  • 표현의 일관성: 평가와 실제 서비스에서 문맥·도구 정보를 표현하는 방식을 맞춰 입력 구성의 차이를 줄임.
  • 상태의 구분: 입력에 상태 정보가 있어도, 실제 도구 호출이 환경을 바꾸고 그 결과를 관찰하는 평가가 자동으로 되는 것은 아님.

긴 대화를 입력해도 한 번의 판단을 평가할 수 있다

입력에 포함된 대화 길이와 평가가 실행하는 범위는 별개다. 이전 대화를 길게 넣더라도 준비된 입력에 대한 다음 출력만 비교하면 한 번의 판단을 분리해서 평가하는 방식이다.

  • 입력 문맥: 이전 발화와 여러 행동 단계를 포함할 수 있음.
  • 판정 단위: 준비된 입력에 대한 한 번의 예측을 기대 출력과 비교.
  • 집계 단위: 개별 판정을 행동 단계(step), 대화 차례(turn), 전체 대화(conversation) 수준으로 묶을 수 있음.
  • 실행 전체(episode) 평가: 실제 예측과 도구 실행 결과가 다음 입력과 환경 상태를 결정하며 목표 달성까지 이어짐.

여기서는 고정 입력에 대한 판단 평가를 single-turn/component 평가라고 부른다. 한 사례가 반드시 첫 발화만 담아야 한다는 뜻은 아니다. 여러 개별 판정을 대화 단위로 집계한 점수 역시 실제 대화를 끝까지 실행한 성공률과 구분해야 한다.

평가 흐름: 사례 구성부터 추론 기록까지

  1. 예제 구성: 사용자 요청, 대화 문맥, 도구 명세로 입력 상태와 기대 출력을 준비.
  2. 입력 생성: 문맥과 도구 정보를 프롬프트로 구성하고, 비교할 정답을 함께 준비.
  3. 추론: 준비된 입력으로 모델을 호출하고 정해진 출력 종료 조건에 따라 예측을 수집.
  4. 기록: 실제 추론에 사용한 입력, 정답, 예측을 묶어 저장.
  5. 채점: 저장된 결과에서 도구 선택과 인자 등 평가 대상에 맞는 비교를 수행.
  • 비교하려는 변경: 모델, 학습 중 저장한 모델 상태(checkpoint), 프롬프트 등 판단을 바꾸는 요소.
  • 고정할 조건: 비교 대상 외의 평가 데이터, 입력 구성, 도구 명세, 추론 설정과 채점 기준.
  • 기록의 장점: 동일한 추론 기록을 두고 오답을 분석하거나 채점 결과를 다시 살펴볼 수 있음.
  • 재현성의 의미: 입력을 고정해도 모델 출력이 항상 같아지는 것은 아님. 우선 비교 조건을 통제하고, 필요한 경우 반복 실행의 변동성을 함께 확인.

생성과 채점을 분리해 읽는다

평가 예제 하나의 실행 순서예제 준비가 입력과 정답을 추론기에 전달한다. 추론기는 모델 출력을 받아 입력과 정답과 함께 저장하고 grader가 사후 비교한다. 한 평가 예제의 준비 · 추론 · 기록 · 채점 예제 준비 모델 호출 모델 결과 / 채점기 입력 + 정답 전처리한 프롬프트 모델 예측 입력 · 정답 · 예측 저장 사후 채점출력 구조와 기대값 비교 모델의 출력과 도구를 실행한 결과는 서로 다른 증거다.

그림 2. 준비된 프롬프트로 추론하고 결과를 저장한 뒤 채점한다. 채점기에 전달하는 예측은 도구를 실행한 결과가 아니라 모델이 생성한 출력이다.

  • 입력 전처리: 입력 표현을 모델 호출 형식에 맞추고 실제 사용한 입력을 기록.
  • 기록할 정보: 입력, 기대 결과, 평가 대상의 종류, 모델 예측과 추론 시간.
  • 간단한 판정: 앞뒤 공백 등을 정리한 출력과 정답의 문자열이 같은지 비교.
  • 구조 판정: 계획을 함수 호출 구조로 해석하고, 함수 이름과 인자를 비교. 중첩된 호출은 내부 구조도 확인.
  • 의미 판정: 표현이 다른 출력도 허용해야 한다면 의미 비교나 별도 모델을 활용한 판정을 검토. 허용할 차이와 채점 기준을 먼저 정의.

문자열 일치율과 구조·의미를 고려한 판정은 같은 지표가 아니다. 어떤 규칙으로 채점했는지 알아야 점수를 해석할 수 있다.

읽고 있는 결과 답하는 질문 추가 확인이 필요한 것
문자열 일치율 정해진 전처리 후 출력이 정답과 같은가? 의미가 같은 다른 표현도 허용하는가?
함수·인자 판정 생성한 호출 구조가 기대 구조에 맞는가? 비교 규칙이 허용하는 차이와 대상 참조 방식
단계·차례·대화별 집계 묶음 안에서 필요한 개별 판정들이 통과했는가? 실제 예측을 다음 실행에 이어 사용했는가?
실제 작업 성공률 환경에서 사용자의 목표를 달성했는가? 도구 실행·상태 변화·최종 상태의 증거

정답 이력으로 여러 단계의 판단을 분리한다

여러 줄의 계획을 평가하는 한 가지 방법은, 이전 단계의 정답을 다음 입력에 붙이는 것이다. 각 판단을 분리해서 볼 수 있는 대신 실제 오류 전파와 복구는 관찰하기 어렵다.

정답 이력로 여러 줄의 계획을 분리 평가하는 순서초기 문맥으로 첫 줄을 예측한다. 평가 예제 구성 단계에서는 실제 예측과 무관하게 첫 정답 줄을 다음 입력에 추가한다. 둘째 예측은 정답 문맥에서 평가된다. 다음 입력에는 실제 예측 대신 정답이 들어간다 평가 예제 구성 모델 채점기 초기 문맥 첫 줄 예측 첫 줄 정답 → 비교 이전 정답 줄을 추가실제 예측에 의존하지 않음 초기 문맥 + 첫 줄 정답 둘째 줄 예측 둘째 줄 정답 → 비교 입력 간 논리적 관계를 표현한 그림 · 배치의 실제 실행 순서는 별개

그림 3. 첫 줄의 실제 예측 대신 첫 줄의 정답을 둘째 입력에 붙인다. 다음 예측은 올바른 이전 문맥이 주어졌을 때의 판단이다.

  1. 분할 결정: 기대 계획이 여러 줄일 때 어떤 단위로 나누어 평가할지 정함.
  2. 첫 예제: 초기 프롬프트를 입력으로, 첫 정답 줄을 기대 출력으로 사용.
  3. 다음 예제: 초기 프롬프트에 이전 정답 줄을 붙이고 다음 줄을 기대 출력으로 사용.
  4. 반복: 실제 예측과 무관하게 앞부분의 정답 이력(gold prefix)을 늘려 평가 입력을 준비.
  • 적용 범위: 줄 단위로 나눌 수 있는 계획의 판단을 분리해 볼 때 사용. 자연어 응답이나 요약처럼 분할이 의미를 바꾸는 출력은 별도의 평가 단위를 정함.
  • 다이어그램의 의미: 입력 간의 의존성을 보여주는 논리적 순서. 배치 추론이 반드시 그림처럼 순차 실행된다는 뜻은 아님.
  • 유용한 질문: 올바른 이전 판단이 주어졌다면 모델이 이번 판단을 맞힐 수 있는가?
  • 남는 질문: 이전 판단이 틀렸을 때 실제 도구는 어떤 결과를 반환하며 모델은 어떻게 복구하는가?

예를 들어 첫 줄에서 잘못된 대상을 선택한 예측이 나와도 둘째 평가 입력에는 정답 대상이 들어갈 수 있다. 둘째 줄의 통과는 그 문맥에서 올바른 함수를 생성했다는 의미이며, 잘못 고른 대상을 실제 실행 중 수정했다는 증거는 아니다.

계획을 맞힌 것과 작업이 성공한 것은 다르다

“10분 타이머 하나 만들어 줘”라는 요청은 같은 발화로도 서로 다른 평가 질문을 만들 수 있다. 아래는 평가 범위를 설명하기 위한 가상 사례이며 실제 측정 결과가 아니다.

확인할 항목 고정 입력 평가로 확인 가능한 범위 실행·상태 평가에 필요한 증거
어떤 도구를 선택했는가? 기대 타이머 생성 함수를 출력했는지 비교 실제 도구 호출 기록
지속시간이 올바른가? 기대 인자에 10분이 표현됐는지 비교 도구의 사용 규칙에 맞게 저장된 지속시간
타이머가 만들어졌는가? 생성 호출을 출력했다는 사실 생성된 타이머의 존재와 활성 상태
정확히 하나인가? 단일 출력이 기대 호출인지 확인 전체 실행 후 중복 생성 여부
실패 후 복구했는가? 오류 문맥을 별도 입력으로 주어 후속 판단을 평가 가능 실제 오류·재시도·복구가 이어진 실행 기록
  • 응답 유실 예시: 도구가 타이머를 생성한 뒤 응답만 유실되면 재시도로 두 개가 만들어질 가능성이 있음.
  • 고정 사례의 역할: “오류 응답을 받은 문맥에서 재시도할 것인가?”라는 판단을 별도 사례로 검사할 수 있음.
  • 추가로 필요한 검증: 실제 도구의 동작에 맞는 오류를 발생시키고 재시도 이후 최종 상태를 확인해야 중복 여부를 알 수 있음.
  • 평가의 경계: 실패 상황을 입력으로 표현할 수는 있음. 다만 모델의 실제 행동으로 그 상황이 발생하고 다음 행동으로 이어지는 과정은 이 평가 경로에 포함되지 않음.

어떤 문제에 활용하면 좋을까

고정 입력 평가는 특정 문맥에서 모델 판단의 변화를 분리해 확인할 때 유용하다.

확인하려는 문제 활용 방법
모델 변경 뒤 도구 선택이 달라졌는가? 같은 사례와 설정에서 예측을 비교
프롬프트 수정으로 인자 오류가 줄었는가? 같은 모델과 사례를 유지하고 입력 구성만 변경
고친 오류가 다시 나타나는가? 알려진 실패를 작은 입력·기대 결과 쌍으로 보존해 반복 검사
긴 계획의 어느 판단에서 틀리는가? 정답 이력으로 각 단계의 판단을 분리
도구 실패가 실제 중복 작업으로 이어지는가? 도구 실행과 상태 변화를 확인하는 평가를 함께 사용
  • 원인 분리: 동일한 문맥에서 어떤 함수·인자를 잘못 생성하는지 비교.
  • 환경 의존성 감소: 업무 도구의 모든 상태 변화와 실패 조건을 재현하기 전에 모델 판단부터 확인.
  • 분석의 편의: 저장한 입력·기대 결과·예측을 함께 보며 입력 문제와 출력 문제를 구분.
  • 점수의 범위: 기대하는 도구가 계획에 포함됐는지만 검사했다면, 모든 인자·순서·실행 효과까지 검증했다고 해석하지 않음.

고정 입력 평가는 실행 환경을 준비하는 부담을 줄이지만, 그만큼 최종 상태에 대해 알 수 있는 범위도 제한된다. 판단을 비교할 때는 입력·기대 결과·채점 규칙을 통제하고, 작업 성공을 확인할 때는 실제 실행과 상태의 증거를 함께 본다.

설명 범위와 함께 읽을 글