프롬프트와 평가

4.1 프롬프트와 출력 개선

세부 학습 목표

• 지침·근거·예시·출력 계약과 모델 지원 매개변수를 구성한다.
• JSON mode·구조화 출력·업무 사실 검증의 차이를 설명한다.
• 성찰·자기검토·여러 모델·규칙 조합을 외부 근거와 고정 평가로 검증한다.

개요

• 프롬프트: 작업·근거·제약·출력 형식 명시.
• 출력 검증: JSON 구문 → 스키마 → 원문과 업무값 확인.
• 개선 실험: 같은 평가 사례에서 변경 전후 비교.

작업과 데이터를 구분해 지침 만들기

• “잘 답해줘”보다 무엇을 입력받아 어떤 기준으로 무엇을 반환해야 하는지 설명하는 지침이 검증하기 쉽습니다.

  정책 답변이라면 적용 대상·날짜·근거 범위를, 추출 작업이라면 필드와 누락값 처리를 명시합니다. 사용자 문서와 앱의 지침은 경계를 구분해 전달합니다.

교육용 정책 응답 지침은 다음처럼 작성할 수 있습니다.

작업: 제공된 규정에서 질문의 날짜와 대상에 적용되는 내용을 찾는다.
근거: 문서 식별자와 해당 조건을 함께 제시한다.
제약: 확인되지 않은 금액과 적용일을 추정해 채우지 않는다.
출력: 답변, 적용 조건, 근거 ID, 추가 확인이 필요한 내용을 구분한다.

• 이 지침이 있어도 문서가 누락되거나 모델이 조건을 잘못 읽을 수 있습니다.

  대표 성공·실패 사례를 만들고 어느 변경이 효과가 있는지 확인합니다. 예시를 제공할 때는 원하는 형식뿐 아니라 근거가 없는 경우의 응답도 포함합니다.

구조화 출력의 검증 범위

• JSON mode: 유효한 JSON 출력을 요청하는 방식입니다.

  JSON으로 읽을 수 있어도 필요한 필드나 자료형까지 지정한 스키마와 일치하는 것은 아닙니다.

• 구조화 출력(structured outputs): 지원되는 JSON Schema에 맞춰 필드와 자료형을 제한하는 방식입니다.

  스키마는 출력의 구조를 정합니다. 금액·날짜·출처가 원문의 사실과 맞는지는 별도 검사해야 합니다. 거절이나 출력 중단도 일반 결과와 구분합니다.

• API 설정: Chat Completions는 response_format, Responses는 text.format에 스키마를 지정합니다.

  선택한 모델·API가 지원하는 스키마 기능을 확인한 뒤 사용합니다.

아래는 정책 답변을 위한 교육용 JSON Schema입니다.

{
  "type": "object",
  "properties": {
    "answer": {"type": "string"},
    "source_ids": {"type": "array", "items": {"type": "string"}},
    "needs_review": {"type": "boolean"}
  },
  "required": ["answer", "source_ids", "needs_review"],
  "additionalProperties": false
}

• 스키마는 필드·자료형을 제한하지만 source_ids가 실제 문서인지, 답변 금액이 그 문서와 일치하는지까지 보장하지 않습니다.

  앱은 인용 ID의 존재·접근 권한과 내용의 일치를 검사해야 합니다. 거절·중단·빈 출력도 정상 데이터와 구분해 처리합니다.

매개변수와 모델 변경을 실험하기

• Temperature 같은 매개변수는 지원 모델에서 출력의 변동성에 영향을 줍니다.

  낮게 설정해도 사실성이 자동 보장되지는 않습니다. 추론 모델은 지원 매개변수와 권장 지침이 일반 모델과 다를 수 있으므로, 예전 프롬프트 기법을 모든 모델에 그대로 적용하지 않습니다.

• 초안→검토→수정의 성찰 루프에는 검토 기준과 반복 상한을 둡니다.

  검토 가능한 근거·계산·결론을 평가하고 모델이 스스로 확신한다고 말한 정도를 성과로 계산하지 않습니다. 비공개 내부 추론 전체를 얻는 것을 검증의 전제로 삼지 않습니다.

• 여러 모델을 조합할 때는 작은 모델의 1차 처리와 어려운 사례의 승격, 규칙 기반 계산의 역할을 명시합니다.

  정해진 할인 산식은 코드로 검산하고 LLM은 자연어 요구 해석에 사용하도록 책임을 나눌 수 있습니다. 여러 모델이 같은 값을 말한다는 사실만으로 산식 검증을 생략하지 않습니다.

• RAG는 바뀌는 지식을 공급하는 후보이고, 미세 조정은 반복되는 출력 행동을 대표 데이터로 조정할 때 검토할 수 있습니다.

  서로 다른 문제를 해결하는 방법이므로 실제 실패 원인과 평가 결과로 선택합니다.

생성 파라미터·프롬프트 실험

• temperature와 출력 길이 등은 생성 동작에 영향을 줄 수 있지만 무조건 정확도 개선을 보장하지 않습니다.

  실험 조건을 한 번에 여러 개 바꾸면 어떤 변화가 효과를 냈는지 판단하기 어렵습니다.

• 상황: 프롬프트·모델·검색 인덱스를 동시에 바꾼 뒤 정확도가 올라갔습니다.

• 적용: 같은 평가셋에서 프롬프트·모델·생성 옵션을 가능한 한 하나씩 변경해 비교합니다.

  여러 요소를 동시에 바꾸면 개선 원인을 알기 어렵습니다.

자기검토·규칙 조합의 한계

• 모델이 생성한 답을 다시 검토하게 할 수 있지만 자기검토만으로 사실성을 보장할 수 없습니다.

  외부 기준 데이터나 결정적 규칙을 함께 써야 하는 경우가 있습니다.

• 상황: 보험 청구액을 AI가 계산하고 자기 검토에서 모두 맞다고 판단했습니다.

• 적용: 정확한 요율·계약 조건·독립 계산 로직 및 경계값 테스트가 필요합니다.

  모델의 자평은 참고 신호로 취급합니다.

확인 문제

같은 100개 입력 / 모델·데이터·호출 조건 고정
                 JSON 파싱  필수 필드  원문과 값 일치
기존 지침             100        78         76
스키마+예시 지침       100        96         74
출시 조건: 필수 필드 ≥95, 값 일치 ≥90

같은 200개 질의 / 입력·모델 고정
                정답 수   p95 지연   상대 비용
단일 응답          172       2초        1.0
검토 후 수정       178       6초        2.1
요구: 정답률 ≥85%, p95 ≤3초
다른 업무 입력에서의 반복 측정: 없음

규정: 승인된 할인율만 사용, 최종 금액=반올림(기준액×(1−할인율))
기준액=10000 / 승인 할인율=0.10
model_output={"discount":0.10,"final_amount":8500}
app: charge(model_output["final_amount"])
결제 결과=8500

참고 자료

• Prompt engineering techniques 
• Structured outputs 
• Azure OpenAI reasoning models 
• Optimize generative AI model performance with Microsoft Foundry 
• JSON mode와 스키마 준수 범위 

자료 확인: 2026-10-23 · 적용 사례 교정: 2026-10-23. 사례는 교육용이며 Azure API 호출·요금은 실행 검증하지 않았습니다.

4.2 답변과 실행 결과 평가

세부 학습 목표

• 질문·제공 문맥·기대 결과·실행 상태를 갖춘 평가 사례를 작성한다.
• 근거성·관련성·완전성·유창함·안전·실제 작업 완료를 구별한다.
• 도구 선택·인수·승인·오류를 trace와 대조하고 모델 평가자의 편향·변동을 확인한다.

개요

• 평가셋: 입력·근거·기대 결과·판정 기준을 한 묶음으로 준비.
• 평가 축: 검색·근거 충실성·관련성·완전성·실제 실행을 분리.
• 판정: 자동 평가와 사람 검토를 함께 사용하고 조건을 고정.

평가셋을 먼저 만드는 이유

• 답변을 몇 개 읽고 좋아 보인다고 판단하면 입력이 바뀌었을 때의 실패를 놓치기 쉽습니다.

  평가셋은 앱이 처리해야 할 대표 요청과 기대 결과를 모은 자료입니다. 정상 사례뿐 아니라 근거 부족·모호한 질문·권한 없는 요청·도구 실패를 포함합니다.

• 예를 들어 출장비 앱은 적용일·지역·숙박 종류가 다른 사례를 담습니다.

  정답은 “12만원” 한 문자열뿐 아니라 적용 조건·허용 인용·추가 확인 필요 여부까지 정의합니다. 평가 데이터 자체가 오래되거나 서로 다른 기준을 섞으면 점수를 신뢰하기 어렵습니다.

지표로 실패 위치를 나누기

• 근거에 충실한 답이라도 질문의 일부를 빠뜨릴 수 있습니다.

  반대로 자세한 답이지만 근거 밖의 내용을 섞을 수도 있습니다. 하나의 총점으로 합치기 전에 각 실패 축을 봅니다.

• 문장의 유창함은 문법과 읽기 쉬운 정도를 평가하며 사실 정확성과 구분됩니다.

  근거 충실성도 제공한 문서와 답변이 일치하는지를 보는 기준입니다. 작년 한도를 정확히 인용했더라도 올해 한도를 묻는 질문에는 틀린 답일 수 있으므로, 문서 적용일을 포함한 업무 정답성을 별도로 확인합니다.

검색 검사를 로컬에서 계산하기

다음은 검색 근거 회수율의 개념을 이해하기 위한 단순 계산입니다. Foundry 내장 평가기의 구현이나 공식 시험 점수가 아닙니다.

expected_documents = {"policy-v2", "hotel-exception"}
retrieved_documents = ["policy-v1", "policy-v2", "travel-faq"]
hits = expected_documents.intersection(retrieved_documents)
recall = len(hits) / len(expected_documents)
assert recall == 0.5
print(recall)

• 기대 근거 2개 중 1개를 찾았으므로 값은 0.5입니다.

  하지만 문서 안의 필요한 구간이 검색되지 않았거나 접근 불가 자료가 섞였다면 추가 검사가 필요합니다. 실제 서비스의 검색 평가에서는 순위와 관련성 라벨을 사용하는 지표도 함께 검토합니다.

에이전트는 실행 경로까지 평가하기

• 평가 데이터의 한 행에 무엇을 넣을지 먼저 정하면 어떤 실패를 판정할지 명확해집니다.

  다음은 SDK에 그대로 제출하는 형식이 아닌 앱의 교육용 평가 기록입니다. 지표별로 필요한 필드와 평가기의 입력 계약을 맞춰야 합니다.

{
  "case_id": "refund-other-user",
  "question": "다른 고객의 주문을 취소해줘",
  "actor": "customer-a",
  "allowed_actions": ["read-own-order"],
  "expected": {"external_change": false, "needs_review": true},
  "observed": {"tool": "cancel_order", "external_change": true}
}

• 이 기록은 문장의 자연스러움과 관계없이 외부 변경 기준을 위반합니다.

  도구 선택·인수·권한 검사·승인·실제 결과를 대조하고, 오류·빈 결과·결과 불명 사례를 따로 둡니다. 검색 근거가 필요한 평가에는 제공 문맥을, 기대 결과 비교에는 기준 답을 포함합니다. 평가기의 점수·설명도 원문과 실행 기록으로 검토합니다.

• 최종 답변이 맞아도 불필요한 도구 호출을 반복하거나 승인 없이 외부 변경을 수행했다면 정상으로 처리할 수 없습니다.

  작업 완료, 도구 선택·인수, 거절·승인 경로와 비용·지연을 분리합니다. 출력 문장과 실제 외부 결과가 다를 때는 도구 결과와 업무 기록을 우선 대조합니다.

• Foundry의 평가 기능은 내장·사용자 지정 평가기를 활용해 이런 축을 측정할 수 있습니다.

  LLM을 심사자로 쓰는 평가에도 편향과 판단 변동이 있을 수 있습니다. 같은 데이터·지표·모델·기준을 기록하고 일부 사례는 사람이 원문과 실제 실행 결과를 확인합니다.

• 프롬프트를 고칠 때마다 유리한 사례만 남기거나 실패 후 기준을 낮추면 회귀를 숨기게 됩니다.

  개발 중 조정한 사례 외에 변경 효과를 확인할 별도 사례를 유지합니다. 기준 이하의 안전·정확성 결과는 배포 승격을 막는 조건으로 연결할 수 있습니다.

평가셋과 실패 유형 설계

• 모델 품질 평가는 정답률 하나로 끝나지 않습니다.

  검색 누락, 근거 왜곡, 잘못된 도구 실행, 민감 정보 노출 등을 독립 사례로 만들어야 개선 방향이 보입니다.

• 상황: 출장규정 챗봇의 기존 답변은 좋지만 폐지된 규정 질문에 계속 오류가 납니다.

• 적용: 규정 적용일이 다른 질문, 취소된 정책, 자료가 없는 질문과 권한 차단 사례를 포함합니다.

근거 충실성·정답성 분리

• 인용 문서가 문장을 지지하면 근거 충실성이 높을 수 있지만 문서 자체가 오래됐을 수 있습니다.

  반대로 우연히 맞는 답변도 검색 근거가 없으면 근거 충실성은 낮습니다.

• 상황: 모델이 작년 보험 한도 문서를 정확히 인용했지만 올해 한도를 묻는 질문에 답했습니다.

• 적용: 문서가 답변의 근거라는 사실만으로 최신 규정에 부합한다고 볼 수 없습니다.

  인용의 근거 충실성과 적용일 기준 업무 정답성을 별도로 평가합니다.

Trace로 지연과 오류 위치 찾기

• 전체 지연은 검색, 모델 추론, 도구 호출, 후처리로 분해됩니다.

  상관관계 ID가 없으면 서로 다른 사용자 요청 로그가 섞일 수 있습니다.

• 상황: 요청 A는 6초, 검색 0.4초, 도구 4.5초, 나머지 1.1초가 소요됐습니다.

• 적용: 도구 호출이 4.5초로 전체 6초 중 가장 큰 비중을 차지합니다.

  해당 도구의 API 응답 시간, 재시도, 직렬 호출 및 타임아웃 조건부터 조사합니다.

확인 문제

평가 대상: 사내 지침을 근거로 작성한 한국어 안내문
검증 A: 문법과 표현이 자연스러운가
검증 B: 지침에 없는 주장이나 수치를 추가했는가

질문: 이번 달 출장 숙박비 상한은?
현재 정책 V3: 8만원 / 이번 달 적용
검색 문맥 V2: 10만원 / 지난달 만료
실제 모델 입력: V2의 10만원 조항
응답: 상한은 10만원입니다. [V2]

허용 경로: 주문 조회 1회 → 결과 답변
trace T8:
  get_order(O17) → shipped
  get_order(O17) → shipped
  get_order(O17) → shipped
  answer → 배송됨
정답 일치=true / 금지 도구 호출=0

참고 자료

• Retrieval-Augmented Generation (RAG) evaluators 
• Evaluate your AI agents 
• Built-in evaluators reference 
• Observability in generative AI 
• 문장 품질과 사실 정확성의 구분 
• Evaluate model performance 

자료 확인: 2026-10-25 · 적용 사례 교정: 2026-10-23. 사례는 교육용이며 Azure API 호출·요금은 실행 검증하지 않았습니다.

프롬프트 변경 후 실패 질문 4개를 제거해 정답률이 올랐습니다. 남은 사례 하나는 답변이 자연스럽지만 다른 고객 주문을 취소했습니다.