기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

고급 주제 및 전략

이 페이지의 주제

다중 목표 최적화

고급 프롬프트 최적화는 실행당 하나의 지표, 즉 샘플당 하나의 스칼라 점수를 허용합니다. 그러나 다중 목표(다차원) 최적화를 암시적으로 지원합니다. 여러 목표를 하나의 스칼라(복합 지표)로 번들링할 수 있으며 서비스는 해당 번들에 대해 프롬프트를 최적화합니다. 이 섹션에서는 권장되는 패턴, 각 패턴이 적절한 시기, 주의해야 할 장애 모드를 다룹니다.

이는 정확도 + 어조, 도구 호출 정확성 + 안전성, 충실도 + 간결성, 지연 시간-친화성 + 완전성 등 둘 이상의 사물을 동시에 신경 쓰는 모든 곳에 적용됩니다.

지표 하나가 실제로 다중 목표인 이유

시스템에 대한 두 가지 사실을 통해이 작업을 수행할 수 있습니다.

따라서 "실행당 하나의 지표"는 최적화할 수 있는 대상에 대한 제한이 아니라 신호 셰이프에 대한 계약입니다.

여러 목표를 단일 지표로 번들링하는 패턴

목표가 서로 어떤 관련이 있는지에 따라 하나를 선택합니다.

패턴 1 - 가중 합계(가장 일반적)

final = w₁·s₁ + w₂·s₂ + ... + wₖ·sₖ가중치 합계가 1인 .

사용 시기: 목표는 거의 독립적이며 순위를 매길 수 있습니다. 절충은 허용됩니다. 합계가 올라가는 한 다른 것을 대신해 개선해도 괜찮습니다.

가중치 선택:

예(에이전시/도구 사용):

final = 0.5 * tool_correctness + 0.3 * answer_correctness + 0.2 * format_compliance

패턴 2 - 하드 장애 게이트(안전에 중요)

하나 이상의 게이팅 목표를 정의합니다. 게이트가 실패하면 나머지에 관계없이 점수는 0(또는 일부 층)입니다. 그렇지 않으면 점수는 나머지 목표의 가중치 합계입니다.

if not safety_check_passed:
    return 0.0
if wrong_tool_called_for_destructive_action:
    return 0.0
return 0.6 * accuracy + 0.4 * tone

사용 시기: 하나 이상의 목표를 협상할 수 없습니다(PII 유출, 잘못된 계정 수정, refusal-on-prohibited-content). 가끔이라도 안전 표시줄에 장애가 발생할 경우 "평균 정상" 프롬프트가 허용되지 않을 때마다 이를 사용합니다.

가중치만 능가하는 이유: 가중치만으로 최적화 프로그램은 품질을 기준으로 안전성을 비교하고 여전히 점수를 언덕을 오를 수 있습니다. 게이트를 사용하면 구성으로 인해 절충이 불가능합니다.

패턴 3 - 제약 + 보상(파레토 스타일)

가장 중요한 목표를 보상으로 선택합니다. 나머지는 위반 시 보상에서 빼는 제약으로 표현합니다(제로 아웃 대신).

reward = task_accuracy
penalty = 0.0
if response_too_long:
    penalty += 0.1
if missed_required_disclosure:
    penalty += 0.2
return max(0.0, reward - penalty)

사용 시기: 하나의 기본 목표를 리드하고 싶지만 소프트 보조 목표는 여전히 프롬프트를 형성해야 합니다. 하드 게이트보다 덜 부서지고 가중치 합계보다 덜 모호합니다.

패턴 4 - Lambda 외부, LLM-as-a-Judge 내부(퍼지 + 구조 혼합에 권장)

Lambda 지표는 결정론적 하위 점수(정규식, JSON 구문 분석, 스키마 검증)를 계산하고 Lambda 함수 내의 퍼지 부분(어조, 충실도, 유용성)에 대한 LLM-as-a-Judge 하위 평가를 호출합니다. 그런 다음 이를 하나의 스칼라로 집계합니다.

def compute_score(prompt, prediction, gold, ...):
    structural = grade_format_and_tools(prediction)        # 0..1 from regex
    semantic   = call_llm_judge(prediction, gold, criteria) # 0..1 from LLMJ
    if structural < 1.0 and is_safety_critical(prompt):
        return 0.0
    return 0.6 * semantic + 0.4 * structural

사용 시기: 목표는 "코드에서 테스트하기 쉬움"(형식, 도구 이름, 길이, 인용의 존재)과 "판단할 모델 필요"(어조, 충실도, 유용성)를 혼합합니다. 결정적 부분이 실행으로 드리프트되지 않기 때문에 종종 하나의 LLM-as-a-Judge 프롬프트에 단일 복합 점수를 생성하도록 요청하는 것보다 더 깔끔합니다. run-to-run

패턴 5 - 다중 차원 LLM-as-a-Judge(Lambda 없음)

내장 LLM-as-a-Judge 흐름을 사용합니다. 선택적으로 자체 차원 및 가중치customLLMJConfig.customLLMJPrompt를 정의하는와 함께 사용합니다. 판사는 차원당 점수와를 내보냅니다. Overall시스템은 [0, 1] 스칼라로 구문 분석합니다Overall(또는 Overall가 누락된 경우 평균 차원).

사용 시기: 모든 목표가 의미 체계/퍼지이며 결정론적 하위 검사가 없습니다. 가장 빠르게 작성할 수 있습니다. 판사 분산 감시 - 최적화 신호로 신뢰하기 전에 동일한 데이터 세트를 두 번 다시 실행하고 점수 안정성을 확인합니다.

패턴 선택

패턴을 결합할 수 있습니다. 일반적인 프로덕션 지표는 "가중 합계 + 안전 관련 하드 장애 게이트"입니다.

주의해야 할 장애 모드

출시 전 체크리스트

멀티턴 및 스테이징 프롬프트 최적화

고급 프롬프트 최적화는 샘플별 평가에 대해 단일 프롬프트 템플릿을 최적화합니다. 기본적으로 턴 인식이 아닙니다. 기본적으로 대화 상자를 반복하거나 특정 턴에서 동작을 최적화할 수 없습니다. 스테이징된 프롬프트는 멀티턴 대화 또는 워크플로가 동일한 프롬프트를 교대로 재사용하는 프롬프트 템플릿이며, 프롬프트 자체에는 워크플로의 각 단계, 단계 또는 단계에 대한 지침이 포함되어 있습니다. 이러한 프롬프트를 최적화하려면 대화 상태를 템플릿의 입력 변수로 평면화하고, 로 세분화하려는 시스템 지침을 베이크하고promptTemplate, 샘플별 참조 응답으로 실제로 관심 있는 회전을 탐색합니다.

이 패턴은 수직에 구애받지 않습니다. 고객 서비스 흐름, 에이전트 도구 사용 루프, 다단계 추론, 자습서, 코드 지원 턴, 문서 기반 QA, 분류 워크플로 등 점점 커지는 컨텍스트에 따라 모델이 반복적으로 호출되는 모든 곳에 적용됩니다.

고급 프롬프트 최적화가 실제로 최적화하는 요소

최적화하려는 모든 것이 promptTemplate 그 안에 있어야 합니다. 샘플마다 다른 사물(대화 기록, 현재 사용자 쿼리, 검색된 컨텍스트)은 입니다{{variables}}. 수정하려는 시스템 지침은 템플릿의 일부입니다. 입력 변수가 없거나 서비스에 다시 쓸 내용이 없습니다.

서비스가 턴 N에서 동작을 개선하도록 하려면 샘플 하나에 대해 렌더링된 prompt-plus-input-variables로 턴 N을 표현referenceResponse하고 원하는 turn-N 모델 출력을 표현합니다.

패턴 A Stage-at-a-time(권장 스타터)

한 번에 대화 상자의 한 단계를 최적화합니다. 각 평가 샘플은 해당 단계 내의 단일 결정점을 나타냅니다.

여기서 "스테이지"는 일관된 성공 기준 집합으로 설명할 수 있는 항목입니다. 세로로 나타낸 예:

패턴 A를 사용해야 하는 경우

템플릿 셰이프

스테이지별 시스템 지침은 템플릿에 베이크됩니다(서비스가 다시 작성하는 내용). 대화 기록과 현재 턴만 변수입니다. 아래 구조는 설명이며, 규정되지 않았습니다. 모델이 가장 잘 처리하는 구분 기호 또는 레이아웃을 사용합니다. 유일한 요구 사항은 (a) 템플릿 내에서 최적화하려는 시스템 지침, (b) 샘플당 변수를 로 참조하는 것입니다{{variablename}}.

You are an assistant in the {STAGE_NAME} phase of a multi-turn task.
- ...the policy / goals / format / tool-use rules for this phase...
- ...constraints the model must satisfy at this point in the conversation...

Conversation so far:
{{conversation_so_far}}

User's current message:
{{user_query}}

샘플 셰이프

{
    "inputVariables": [
        {"conversation_so_far": "user: ...\nassistant: ...\n... (turns 1..N-1)"},
        {"user_query": "...the user input that triggers this stage..."}
    ],
    "referenceResponse": "...the assistant output that satisfies the stage's success criteria..."
}

장단점

장점: 엄격한 피드백 신호, 더 작은 프롬프트, 더 빠른 최적화 실행, 집중된 지표 작성 용이.

단점: 스테이지 간 드리프트를 포착하지 않습니다. 스테이지당 한 번씩 서비스를 실행하며 최종 통합 테스트가 필요할 수 있습니다.

패턴 B - 완전히 평면화된 대화(고급)

전체 다단계 정책을 소유하는 하나의 큰 모놀리식 프롬프트를 최적화합니다. 각 샘플은 프로브 회전까지의 전체 대화 상자입니다.

패턴 B를 사용해야 하는 경우

템플릿 셰이프

전체 모놀리식 다단계 시스템 프롬프트는 문자 그대로 템플릿 내부에 있습니다. 서비스는 최적화 중에이 본문을 다시 작성합니다. 기록과 현재 턴은 변수로 유지됩니다. 모델이 잘 처리하는 레이아웃을 선택합니다. 최적화할 지침은 템플릿의 일부일 뿐이며 샘플별 데이터는를 통해 참조됩니다{{name}}.

You are an assistant for {TASK}. The conversation may proceed through phases:
1. {PHASE_1} — ...
2. {PHASE_2} — ...
3. {PHASE_3} — ...
(...the entire multi-phase policy, tool-use rules, tone, formatting, refusal rules...)

Conversation so far (turns 1..N-1, with role tags):
{{conversation_so_far}}

User's current message:
{{user_query}}

샘플 셰이프(모든 턴의 프로브 N)

{
    "inputVariables": [
        {"conversation_so_far": "user: ...\nassistant: ...\n[tool_call: X(...)]\n... (turns 1..N-1)"},
        {"user_query": "...the user input at turn N..."}
    ],
    "referenceResponse": "...desired assistant output at turn N..."
}

패턴 B가 패턴 A보다 더 잘 작동하는 이유

패턴 B에 대한 주의 사항

특정 턴에서 도구 호출 확인

서비스에 어시스턴트의 텍스트 출력이 표시됩니다. "Did the model call tool X with right args at turn N" 등급을 매기려면 하나를 선택합니다.

여러 차례 또는 여러 하위 검사(도구 정확성, 어조 및 완전성)의 복합 기준은 다중 목표 최적화 섹션을 참조하세요.

권장 경로

멀티턴에 고급 프롬프트 최적화를 사용하지 않는 경우

스타터 체크리스트