AI Engineering Tools

Generative AI Engineering

AI 프롬프트 테스트·최적화 용어

프롬프트 테스트 사례를 만들고 통제된 변형을 비교하며 실패·회귀를 분석하고 품질·지연시간·비용의 균형을 잡는 용어를 설명합니다.

16 개 용어

테스트 데이터

프롬프트 테스트 케이스

Prompt test case

뜻

프롬프트를 확인하기 위해 입력, 문맥, 기대 행동, 평가 규칙을 정의한 사례입니다.

언제 쓰나

일반 요청, 경계 조건, 모호한 입력, 예상 거절 상황을 포함해 만듭니다.

활용 예시

Input: missing account ID; expected behavior: request the ID without inventing one.

테스트 데이터

골든 데이터셋

Golden dataset

뜻

대표 테스트 입력과 신뢰할 수 있는 기대 결과 또는 채점 기준을 검토해 모은 데이터셋입니다.

언제 쓰나

릴리스마다 프롬프트 변경을 일관되게 비교할 때 사용합니다.

주의

실제 사용이 바뀌면 데이터셋을 갱신하되 안정적인 회귀 검사 하위 집합은 유지합니다.

활용 예시

Keep 200 reviewed support cases with expected category, required facts, and prohibited claims.

실험

기준 프롬프트

Baseline prompt

뜻

비교의 기준점으로 사용하는 현재 프롬프트 또는 가장 단순한 프롬프트입니다.

언제 쓰나

최적화 전에 기록해 개선 효과를 측정할 수 있게 합니다.

활용 예시

Baseline v12 uses the production model, default parameters, and unchanged retrieval settings.

실험

프롬프트 변형

Prompt variant

뜻

기준안과 비교하는 다른 문구, 구조, 예시 집합, 모델 또는 추론 설정입니다.

언제 쓰나

결과를 재현하고 안전하게 승격할 수 있도록 변형에 이름과 버전을 부여합니다.

활용 예시

Variant B moves constraints after the source and adds one negative example.

실험

통제 실험

Controlled experiment

뜻

관련 입력과 설정은 고정하고 의도한 한 가지 요인만 바꾸는 비교 실험입니다.

언제 쓰나

관찰된 차이가 모델, 데이터, 샘플링이 아니라 프롬프트 변경 때문인지 판단할 때 사용합니다.

활용 예시

Change only the instruction wording; keep the dataset, model version, temperature, and evaluator fixed.

실험

A/B 테스트

A/B test

뜻

비슷한 트래픽이나 테스트 표본에서 두 프롬프트 또는 설정 버전을 비교하는 실험입니다.

언제 쓰나

오프라인 검사 후 실제 운영 동작과 사용자 결과를 비교해야 할 때 사용합니다.

주의

대상 조건, 모니터링, 중단 기준으로 사용자를 보호하고 고위험 워크플로를 검토 없이 실험하지 마세요.

활용 예시

Randomly route eligible requests to A or B and compare task success, corrections, latency, and cost.

실험

프롬프트 절제 실험

Prompt ablation

뜻

프롬프트 구성 요소 하나를 제거하거나 바꿔 그 기여도를 측정하는 실험입니다.

언제 쓰나

품질 개선 없이 비용만 늘리는 불필요한 지시, 예시, 문맥을 찾을 때 사용합니다.

활용 예시

Remove the third example while keeping every other component unchanged.

평가

일괄 평가

Batch evaluation

뜻

준비된 많은 사례에 프롬프트를 실행하고 개별 및 전체 결과를 집계하는 평가입니다.

언제 쓰나

소수 결과의 육안 확인을 대표 성능으로 오해하지 않도록 사용합니다.

활용 예시

Run all prompt variants on the fixed evaluation set and export per-case failures.

평가

프롬프트 회귀

Prompt regression

뜻

프롬프트, 모델, 검색, 도구, 정책 변경 후 이전에 잘 동작하던 행동이 나빠지는 현상입니다.

언제 쓰나

안정적인 테스트 모음으로 추적하고 매 릴리스 전에 결과를 비교합니다.

활용 예시

The new concise format improved length but stopped including required source IDs.

신뢰성

강건성 테스트

Robustness test

뜻

현실적인 표현 변화, 잡음, 언어, 경계 사례에서도 허용 가능한 행동이 유지되는지 확인하는 테스트입니다.

언제 쓰나

바꿔 쓴 표현, 문맥 순서 변경, 오타, 누락 필드, 혼동을 유도하는 입력을 사용합니다.

활용 예시

Test the same intent with formal, conversational, misspelled, and multilingual wording.

신뢰성

민감도 테스트

Sensitivity test

뜻

입력이나 설정의 작은 변화에 출력이 얼마나 크게 달라지는지 측정하는 테스트입니다.

언제 쓰나

문구, 예시 순서, 온도, 문맥 위치, 모델 버전 변화에 적용합니다.

활용 예시

Move the same evidence from the beginning to the middle and compare citation accuracy.

신뢰성

실패 유형 체계

Failure taxonomy

뜻

프롬프트 실패를 일관되게 분류하고 분석하는 범주 체계입니다.

언제 쓰나

대규모 평가 전에 정의해 실패 개수뿐 아니라 원인을 우선순위화합니다.

활용 예시

Labels: missing fact, unsupported claim, schema error, wrong tool, unsafe disclosure, excessive latency.

평가

허용 기준값

Acceptance threshold

뜻

프롬프트 버전이 배포 전에 충족해야 하는 점수나 규칙을 미리 선언한 값입니다.

언제 쓰나

위험도에 따라 정하고 평균 점수뿐 아니라 반드시 통과해야 하는 사례를 포함합니다.

활용 예시

Release only if required-field accuracy is at least 98% and no critical privacy case fails.

평가

모델·파라미터 조합표

Model and parameter matrix

뜻

여러 모델 버전과 추론 설정에서 프롬프트를 비교하도록 계획한 조합표입니다.

언제 쓰나

모델 이전이나 파라미터 변경 후 프롬프트 동작이 달라질 수 있을 때 사용합니다.

활용 예시

Evaluate prompt v8 on model A and B at two supported temperature settings.

효율

품질·지연시간·비용 비교

Quality, latency, and cost comparison

뜻

각 후보의 작업 품질, 응답 시간, 자원 사용량을 함께 비교한 결과입니다.

언제 쓰나

조금 더 정확하지만 작업에 비해 지나치게 느리거나 비싼 프롬프트를 선택하지 않도록 사용합니다.

활용 예시

Compare pass rate, p95 latency, input tokens, output tokens, and estimated cost per successful task.

효율

프롬프트 최적화 반복 과정

Prompt optimization loop

뜻

목표 정의, 기준안 테스트, 실패 분석, 프롬프트 변경, 재테스트를 반복하는 과정입니다.

언제 쓰나

근거에 기반한 작은 변경을 적용하고 각 반복 결과를 버전별로 보존합니다.

활용 예시

Define metric -> run baseline -> label failures -> change one component -> rerun -> review regressions.

프롬프트 최적화 작업 순서

단계필요한 근거
목표 정의사용자 결과, 품질 기준, 위험, 지연시간, 비용 제한
기준안 확립버전 프롬프트, 모델, 설정, 데이터셋, 사례별 결과
변경 테스트통제된 변형, 필요 시 반복 실행, 실패 유형
배포 또는 기각허용 기준, 회귀 검토, 사람 승인, 롤백 계획

자주 묻는 질문

몇 개의 출력만 직접 확인하면 왜 충분하지 않나요?

몇 개의 예시만으로는 일반적인 실패, 경계 사례, 표현 변화, 회귀를 놓칠 수 있습니다. 결론을 내리기 전에 대표 사례, 안정적인 채점 규칙, 사례별 검토, 일괄 결과를 사용해야 합니다.

프롬프트는 정확도만 기준으로 최적화해야 하나요?

아닙니다. 필수 사실, 근거성, 형식 유효성, 안전, 강건성, 지연시간, 토큰 사용량, 비용, 사람 수정 노력 등 작업을 반영하는 지표를 선택해야 합니다.

한 번의 실험에서 프롬프트 구성 요소를 몇 개 바꿔야 하나요?

원인을 판단하려면 주요 요인 하나씩 바꾸는 것이 좋습니다. 여러 요소를 바꾼 후보 비교는 어떤 완성 후보가 나은지는 보여주지만 차이를 만든 구성 요소는 알려주지 못합니다.

공식 참고 자료

관련 용어 페이지