기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # 고급 주제 및 전략 ## 이 페이지의 주제 + [다중 목표 최적화](#advanced-prompt-optimization-multi-objective) + [멀티턴 및 스테이징 프롬프트 최적화](#advanced-prompt-optimization-multi-turn) ## 다중 목표 최적화 고급 프롬프트 최적화는 실행당 하나의 지표, 즉 샘플당 하나의 스칼라 점수를 허용합니다. 그러나 다중 목표(다차원) 최적화를 암시적으로 지원합니다. 여러 목표를 하나의 스칼라(복합 지표)로 번들링할 수 있으며 서비스는 해당 번들에 대해 프롬프트를 최적화합니다. 이 섹션에서는 권장되는 패턴, 각 패턴이 적절한 시기, 주의해야 할 장애 모드를 다룹니다. 이는 정확도 \+ 어조, 도구 호출 정확성 \+ 안전성, 충실도 \+ 간결성, 지연 시간-친화성 \+ 완전성 등 둘 이상의 사물을 동시에 신경 쓰는 모든 곳에 적용됩니다. ### 지표 하나가 실제로 다중 목표인 이유 시스템에 대한 두 가지 사실을 통해이 작업을 수행할 수 있습니다. + **지표는 샘플당 단일 부동 소수점 값을 반환합니다.** 최적화 피드백 루프는이 스칼라를 최적화 신호로 읽습니다. 후드 아래의 하위 점수를 원하는 수만큼 계산할 수 있습니다. + **두 지표 백엔드 모두 이미 하위 점수를 내부적으로 집계합니다.** + 기본 LLM-as-a-Judge 템플릿은 세 가지 차원(응답 정확도, 답변 완전성, 표현식 품질)에서 등급을 매기고 가중치를 할당하며 [0, 1]로 정규화된 단일 `Overall` 점수를 내보냅니다. 사용자 지정 기준은 동일한 스칼라에 병합됩니다. 자세한 내용은 [사용자 지정 LLM-as-a-judge](advanced-prompt-optimization-evaluation.md#advanced-prompt-optimization-evaluation-llmj) 단원을 참조하십시오. + Lambda/사용자 지정 코드 지표는 하나의 숫자를 반환하며 하위 객체의 복합을 포함하여 계산 방법을 제어합니다. 따라서 "실행당 하나의 지표"는 최적화할 수 있는 대상에 대한 제한이 아니라 신호 셰이프에 대한 계약입니다. ### 여러 목표를 단일 지표로 번들링하는 패턴 목표가 서로 어떤 관련이 있는지에 따라 하나를 선택합니다. #### 패턴 1 - 가중 합계(가장 일반적) `final = w₁·s₁ + w₂·s₂ + ... + wₖ·sₖ`가중치 합계가 1인 . **사용 시기:** 목표는 거의 독립적이며 순위를 매길 수 있습니다. 절충은 허용됩니다. 합계가 올라가는 한 다른 것을 대신해 개선해도 괜찮습니다. **가중치 선택:** + 데이터 세트의 빈도가 아닌 사용자에 대한 중요도별 가중치입니다. + 대략적으로 시작: 괜찮`0.5 / 0.3 / 0.2`습니다. 가중치를 과도하게 조정하지 마세요. 이는 별도의 최적화 문제입니다. **예(에이전시/도구 사용):** ``` 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`가 누락된 경우 평균 차원). **사용 시기:** 모든 목표가 의미 체계/퍼지이며 결정론적 하위 검사가 없습니다. 가장 빠르게 작성할 수 있습니다. 판사 분산 감시 - 최적화 신호로 신뢰하기 전에 동일한 데이터 세트를 두 번 다시 실행하고 점수 안정성을 확인합니다. ### 패턴 선택 | \# | 다음과 같은 작업이 있습니다. | 사용 | | --- | --- | --- | | 1 | 2\~4개의 퍼지 목표, 모두 의미 체계 | 패턴 5(다차원 LLM-as-a-Judge) | | 2 | 구조와 의미가 혼합된 2\~4개 목표 | 패턴 4(Lambda 외부 \+ LLM-as-a-Judge 내부) | | 3 | 협상할 수 없는 안전성/정확성 기준 하나 이상 | 패턴 2(하드 장애 게이트) - 1 또는 4와 결합 | | 4 | 하나의 명확한 기본 목표 \+ 소프트 기본 설정 | 패턴 3(제약 \+ 보상) | | 5 | 몇 가지 대략 동일한 독립 목표 | 패턴 1(가중 합계) | 패턴을 결합할 수 있습니다. 일반적인 프로덕션 지표는 "가중 합계 \+ 안전 관련 하드 장애 게이트"입니다. ### 주의해야 할 장애 모드 + **표면 형태의 보상 해킹.** 하위 점수가 '응답에 'sure'라는 단어가 포함되어 있습니까?'인 경우 최적화 프로그램은 모든 출력에 'sure'를 강제로 적용하는 프롬프트를 작성합니다. 키워드 존재보다 결과 기반 하위 점수(도구 이름, 슬롯 값, 구조적 유효성)를 선호합니다. + **드리프트를 판단합니다.** (판사가 선택하라는 요청을 받기 때문에) 호출당 가중치가 다른 다중 차원 LLM-as-a-Judge 지표는 노이즈 최적화 신호를 제공합니다. 사용자 지정 기준에 가중치를 고정하거나 차원 가중치를 Lambda 코드로 이동합니다. + **복합 점수는 포화됩니다.** 지표가 0.95에 빠르게 도달하여 그대로 유지되면 하위 점수가 너무 관대합니다. 마찰을 조이십시오. 최적화 프로그램에 헤드룸이 있도록 최대 막대를 늘리는 것이 좋습니다(예: 부분 크레딧이 1이 아닌 0이 됨). + **하위 목표가 직접 충돌합니다.** "간결성"과 "완전성"은 진정한 장단점입니다. 가중 합계 패턴은 해당 경계의 작동점을 선택합니다.이 패턴이 마음에 들지 않으면 가중치를 변경합니다. ### 출시 전 체크리스트 + 전체 데이터 세트에 대해 초기 프롬프트의 지표를 계산하고 스칼라뿐만 아니라 차원당 평균을 검사합니다. 한 차원이 이미 포화 상태인 경우 번들에서 삭제하는 것이 좋습니다. + 5개의 샘플을 직접 스팟 확인합니다. 지표의 결과가 사용자의 판단과 일치합니까? 그렇지 않은 경우 프롬프트를 최적화하기 전에 지표를 수정합니다. ## 멀티턴 및 스테이징 프롬프트 최적화 고급 프롬프트 최적화는 샘플별 평가에 대해 단일 프롬프트 템플릿을 최적화합니다. 기본적으로 턴 인식이 아닙니다. 기본적으로 대화 상자를 반복하거나 특정 턴에서 동작을 최적화할 수 없습니다. *스테이징된 프롬프트*는 멀티턴 대화 또는 워크플로가 동일한 프롬프트를 교대로 재사용하는 프롬프트 템플릿이며, 프롬프트 자체에는 워크플로의 각 단계, 단계 또는 단계에 대한 지침이 포함되어 있습니다. 이러한 프롬프트를 최적화하려면 대화 상태를 템플릿의 입력 변수로 평면화하고, 로 세분화하려는 시스템 지침을 베이크하고`promptTemplate`, 샘플별 참조 응답으로 실제로 관심 있는 회전을 탐색합니다. 이 패턴은 수직에 구애받지 않습니다. 고객 서비스 흐름, 에이전트 도구 사용 루프, 다단계 추론, 자습서, 코드 지원 턴, 문서 기반 QA, 분류 워크플로 등 점점 커지는 컨텍스트에 따라 모델이 반복적으로 호출되는 모든 곳에 적용됩니다. ### 고급 프롬프트 최적화가 실제로 최적화하는 요소 + **입력:** `{{placeholder}}` 변수가 있는 `promptTemplate` 문자열입니다. + **샘플당:** 각는 해당 변수 및에 대한 값을 `evaluationSamples[i]` 제공합니다`referenceResponse`. 최적화 프로그램은 샘플당 독립적으로 추론, 평가, 피드백 및 재작성을 실행한 다음 샘플 간에 지표를 집계합니다. + **출력:** 세분화된 `promptTemplate`. 변수, 데이터 세트 및 지표는 고정 입력이며 템플릿만 변경됩니다. 최적화하려는 모든 것이 `promptTemplate` 그 안에 있어야 합니다. 샘플마다 다른 사물(대화 기록, 현재 사용자 쿼리, 검색된 컨텍스트)은 입니다`{{variables}}`. 수정하려는 시스템 지침은 템플릿의 일부입니다. 입력 변수가 없거나 서비스에 다시 쓸 내용이 없습니다. 서비스가 턴 N에서 동작을 개선하도록 하려면 샘플 하나에 대해 렌더링된 prompt-plus-input-variables로 턴 N을 표현`referenceResponse`하고 원하는 turn-N 모델 출력을 표현합니다. ### 패턴 A Stage-at-a-time(권장 스타터) 한 번에 대화 상자의 한 단계를 최적화합니다. 각 평가 샘플은 해당 단계 내의 단일 결정점을 나타냅니다. 여기서 "스테이지"는 일관된 성공 기준 집합으로 설명할 수 있는 항목입니다. 세로로 나타낸 예: + **에이전트/도구 사용:** 계획-형식 전환, 도구-선택 전환, tool-result-interpretation 전환, 최종-응답 전환. + **고객 지원:** 접수, 확인, 조치, 확인, 종료. + **자습/학습:** 평가-지식, 설명-개념, 점검-이해, 요약. + **문서 QA:** 검색 기반 답변, 후속 설명, 인용 턴. + **코딩 도우미:** spec-clarification, 코드 생성, 코드 검토/수정, 테스트-쓰기. #### 패턴 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를 사용해야 하는 경우 + 프로덕션 프롬프트는 이미 모놀리식이므로 분할하고 싶지 않습니다. + 옵티마이저가 이전 턴이 나중에 어떻게 설정되는지 확인하여 재작성하면 교차 단계 흐름이 보존됩니다. + 프로브 교체 시 정확성은 여러 단계에 걸쳐 구축된 컨텍스트에 따라 달라집니다(예: "N으로 올바른 사실을 이미 참조해야 함" 또는 "올바른 도구를 이미 호출했어야 함"). #### 템플릿 셰이프 전체 모놀리식 다단계 시스템 프롬프트는 문자 그대로 템플릿 내부에 있습니다. 서비스는 최적화 중에이 본문을 다시 작성합니다. 기록과 현재 턴은 변수로 유지됩니다. 모델이 잘 처리하는 레이아웃을 선택합니다. 최적화할 지침은 템플릿의 일부일 뿐이며 샘플별 데이터는를 통해 참조됩니다`{{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보다 더 잘 작동하는 이유 + 최적화 프로그램은에서 단계 진행 상황을 확인`conversation_so_far`하므로 최적화 피드백은 모든 단계에서 한 번에 추론할 수 있습니다. + 최적화된 단일 프롬프트는 최적화된 여러 스테이지 프롬프트를 함께 연결하지 않고 배포되므로 사후 처리가 줄어듭니다. #### 패턴 B에 대한 주의 사항 + **이전 턴의 확률성.** 프로덕션 어시스턴트 회전은 항상 미리 준비된와 `conversation_so_far` 정확히 일치하지 않을 수 있습니다. 미리 준비된 기록을 예상 궤적으로 취급합니다. 프로덕션에서는 이전 턴의 드리프트로 인해 최적화가 무효화될 수 있습니다. 합성된 행복 경로보다는 대표적인 실제 대화 캡처를 사용합니다. + **토큰 비용.** 긴 기록 시험당 풍선 추론 비용. 서비스는 많은 후보 × 샘플 × 반복을 실행합니다. 그에 따라 예산을 책정하고 비용이 병목 현상인 경우 가장 최근 K턴과 요약으로 잘라내는 것이 좋습니다. + **참조 응답 편향.**는 해당 기록을 고려할 때 올바른 어시스턴트가 말하는 내용이어야 `referenceResponse` 합니다. 참조 응답이 너무 좁으면(허용되는 문구 하나만) 옵티마이저가 이에 과적합합니다. 가능하면 표면 형식 일치보다 결과(도구 이름, 슬롯 값, 결정)의 등급을 매기는 지표를 선호합니다. ### 특정 턴에서 도구 호출 확인 서비스에 어시스턴트의 텍스트 출력이 표시됩니다. "Did the model call tool X with right args at turn N" 등급을 매기려면 하나를 선택합니다. + **출력의 규칙:** 어시스턴트가 Lambda 지표에서 정규식/JSON 구문 분석으로 `X(arg=...)` 및 등급과 같은 구조화된 토큰을 내보내도록 합니다. 가장 저렴하고 안정적입니다. + **LLM-as-a-Judge 사용자 지정 기준:** 판사에게 “응답이 (a) 도구의 이름을 로 지정하고`X`, (b) 인수를 포함하고`arg`, (c) 필요한 단어와 일치`Y`합니까?”`customLLMJPrompt`라고 묻는를 제공합니다. 각 하위 검사는 \+1이며 집계됩니다. 작성하기 쉽고 더 많은 분산이 있습니다. + **다운스트림 시뮬레이션이 포함된 Lambda 지표:** 도구 실행 하네스가 있는 경우 이를 통해 모델 출력을 실행하고 관찰된 부작용에 대한 점수를 매깁니다. 가장 높은 충실도, 대부분의 설정. 여러 차례 또는 여러 하위 검사(도구 정확성, 어조 및 완전성)의 복합 기준은 [다중 목표 최적화](#advanced-prompt-optimization-multi-objective) 섹션을 참조하세요. ### 권장 경로 + 품질이 가장 좋지 않은 스테이지에서 **패턴 A로 시작합니다**. 작업 지표, 20\~50개의 샘플 데이터 세트 및 하나의 최적화 실행end-to-end 가져옵니다. 이렇게 하면 더 큰 패턴 B 실행에 투자하기 전에 데이터세트와 지표가 검증됩니다. + **그런 다음 전체 모놀리식 프롬프트와 다중 목표 복합 지표를 사용하여 패턴 B를 한 번 실행**하여 교차 단계 회귀를 포착합니다 패턴 A는 놓칠 수 있습니다. + **프롬프트를 반복하기 전에 데이터 세트를 반복합니다.** 서비스의가 지표를 다시 작성하지만 프로덕션 동작이 개선되지 않는 경우 지표 또는 데이터 세트가 문제가 될 수 있습니다. ### 멀티턴에 고급 프롬프트 최적화를 사용하지 않는 경우 + **대화 정책/상태 시스템 버그**(잘못된 스테이지 전환 로직): 플랫 프롬프트 재작성으로이 문제를 해결할 수 없습니다. 오케스트레이션 계층을 먼저 수정합니다. + **도구 스키마가 잘못됨:** 서비스가 도구 정의를 변경하지 않습니다. 모델을 사용하도록 요청하는 프롬프트만 변경할 수 있습니다. + **미리 준비된 기록과 실시간 기록 간의 드리프트:** 실제 대화가 몇 차례 후 평가 샘플에서 크게 벗어나면 패턴 B의 최적화 신호가 약해집니다. 최적화 실행을 위해 허용 가능한 실제 프로덕션 트레이스를 캡처하면 이상적인 상태 외에도 도움이 될 수 있습니다. + **필수 동작은 최적화 프로그램이 볼 수 없는 프라이빗 상태에 따라 달라집니다**(예: 모델이 도구 호출을 통해서만 학습하는 사용자 계정 데이터). 프로브 샘플에 `conversation_so_far` 대해에서 해당 상태를 명시적으로 지정하거나 서비스가 표면 동작만 조정할 수 있도록 수락합니다. ### 스타터 체크리스트 + 관심 있는 프로브 회전을 선택합니다. 각각은 하나 이상의 샘플이 됩니다. + 패턴 A 또는 B(또는 둘 다 - A를 먼저 결정한 다음 B)를 결정합니다. + 사실`conversation_so_far`적이고 깨끗한 `referenceResponse` 값으로 20개 이상의 대표 샘플을 빌드합니다.