Realtime 모델 프롬프팅

Realtime 모델 프롬프팅 (Prompting Realtime models)

GPT-Live용 프롬프팅은 별도 가이드를 참고하세요. 여기서는 Realtime API 모델(gpt-realtime-2, gpt-realtime-1.5)을 다룹니다. 낮은 지연 시간으로 음성↔음성(speech-to-speech) 앱을 만들 때 어떤 프롬프트를 짜면 좋은지 정리했어요.

출처: 문서

본문

모델 고르기

모델	언제 쓰나요	프롬프팅 초점
`gpt-realtime-2`	가장 강력한 실시간 추론, 도구 사용, 지시 따름이 필요할 때	reasoning effort, preamble, 도구 정책, 정확한 엔티티 캡처, 긴 세션 상태 튜닝
`gpt-realtime-1.5`	빠르고 신뢰할 수 있는 비추론 음성↔음성 모델이 필요할 때	핵심 실시간 프롬프트 구조와 지연 시간 민감 동작 테스트

Realtime 2.0 프롬프팅 가이드

음성 에이전트가 더 강한 추론, 도구 선택, 정확한 엔티티 처리, 긴 세션 상태가 필요할 때 gpt-realtime-2를 쓰세요. reasoning.effort: "low"로 시작하고, 기본 preamble 동작을 테스트한 뒤, 쓰기(write) 동작 전에 확실한 확인 경계를 정의하세요.

Realtime 2에서 달라진 점

Realtime 2는 단순 음성 봇이 아니라 추론하는 음성 에이전트로 프롬프트하세요.

변화	프롬프트에 주는 의미
추론(Reasoning)	복잡한 작업은 말하거나 도구를 호출하기 전에 내부적으로 추론하게 하세요. 어색한 정적이나 불필요한 잡담을 막으려면 preamble을 쓰세요.
프롬프트 정밀도가 더 중요	"도움이 되게" 같은 광범위한 지시 대신, 명확한 트리거·행동·예외 규칙(언제/무엇을/언제 하지 말지)으로 바꾸세요.
지시 충돌의 비용이 더 큼	정말 필요하지 않으면 겹치는 `always`, `never`, `only`, `must` 규칙을 제거하세요. 규칙이 경합할 때 우선순위를 정의하세요.
도구 동작을 더 잘 제어	언제 즉시 행동하고, 빠진 정보를 물어보고, 높은 정밀도 세부를 확인하고, 실패 후 재시도하거나 에스컬레이션할지 지정하세요.
Preamble이 일급 동작	길게 추론하거나 도구를 쓸 때 짧은 업데이트를 말할 수 있어요. 언제/얼마나 짧게/생략할지 조정하세요.
확장된 컨텍스트 윈도우	실시간 컨텍스트 윈도우가 32k → 128k 토큰으로 늘었어요. 긴 세션과 큰 system prompt에 적합해요.

Preamble은 숨겨진 chain-of-thought가 아니에요. "지금 그 주문을 확인해 볼게요." 같은 짧은 음성 업데이트입니다. 모델에게 비공개 추론을 드러내라고 요청하지 마세요.

권장 프롬프트 구조

짧고 라벨이 붙은 섹션을 쓰세요. 모델이 관련 지시를 빨리 찾을 수 있어야 해요.

# Role and Objective
# Personality and Tone
# Language
# Reasoning
# Message Channels
# Preambles
# Verbosity
# Tools
# Unclear Audio
# Entity Capture
# Long Context Behavior
# Escalation

모든 유스케이스에 모든 섹션이 필요한 건 아니에요. 제품에 맞는 섹션만 추가하세요.

reasoning effort 설정

gpt-realtime-2는 지연 시간을 추론 깊이와 맞바꿀 수 있어요. 워크플로우에 충분한 지능을 주면서 가장 낮은 수준부터 쓰세요. 대부분의 프로덕션 음성 에이전트는 low로 시작하는 걸 권장합니다.

Effort	언제 쓰나요	예
`minimal`	지연 시간이 최우선이고 작업이 단순할 때	스마트홈 명령, 타이머, 간단한 캘린더 확인
`low`	응답성 + 기본 추론	고객 지원, 주문 조회, 간단한 정책 질문
`medium`	다단계 작업을 추론해야 할 때	기술 지원, 진단, 복잡한 라우팅
`high`	더 깊은 추론이 성공을 실질적으로 높일 때	고정밀 워크플로우, 에스컬레이션 결정
`xhigh`	최대 추론이 추가 지연·비용을 감수할 만할 때	복잡한 계획, 중요한 트리아지, 고위험 도구 오케스트레이션

API 설정 외에도, 언제 얼마나 추론할지 프롬프트로 조정합니다:

## Reasoning
- For direct answers, simple lookups, and short confirmations, respond quickly and do not reason.
- For multi-step tasks, tool decisions, troubleshooting, or escalation, reason before acting.
- Do not perform extended reasoning when the user's audio is unclear; ask for clarification instead.

preamble을 의도적으로 쓰기

Preamble은 에이전트가 추론·조회·도구 호출을 하는 동안 응답성 있게 느껴지게 하는 짧은 음성 업데이트예요. 잘 쓰면 사용자에게 "작업 중"임을 안심시키고, 못 쓰면 잡담이 되어 지연이 체감됩니다. gpt-realtime-2는 기본적으로 preamble을 생성해요. 기본 동작을 먼저 테스트하고, 제품 경험과 안 맞으면 명시적으로 튜닝하세요.

## Preambles
Use short preambles only when they help the user understand that work is happening.

### When to use a preamble
Use a preamble when:
- you are about to call a tool that may take noticeable time;
- you need to reason through a multi-step request;
- you are checking records, availability, account state, or policy details;
- you are preparing an escalation or handoff;
- silence would make the assistant feel unresponsive.

When a preamble is needed, output it immediately before substantive reasoning or tool use.

### When to not use a preamble
Do not use a preamble when:
- the answer is direct and can be given immediately;
- the user is only confirming, correcting, or declining something;
- the audio is unclear and you need clarification;
- the latest audio is silence, background noise, hold music, TV audio, or side conversation;
- the tool call is lightweight and the user would not benefit from an update.

### Preamble style
- keep it natural, calm, and concise;
- vary the wording across turns;
- describe the action, not the internal reasoning;
- avoid filler.

Avoid phrases like: "Let me think...", "Hmm...", "One moment while I process that...", "I am now going to access the tool..."

### Preamble length
Use one short sentence. Do not exceed two short sentences unless the user needs an explanation before a high-impact action.

응답 길이 제어

각 작업 유형별로 어느 정도의 세부 정보를 줄지 지정해 주는 게 가장 잘 통합니다. "간결하게"라고만 말하지 말고, 문맥에서 간결함이 무엇인지 정의하세요.

## Verbosity
- Direct answers: Use 1-2 short sentences.
- Clarifying questions: Ask one question at a time.
- Tool results: Summarize the result first, then give only the next useful action.
- Product or option comparisons: Include key differences, tradeoffs, and who each option fits.
- Troubleshooting: Give one step at a time unless the user asks for the full procedure.
- Escalations: Briefly explain why escalation is needed and what will happen next.

도구 동작 설계

gpt-realtime-2는 도구 호출이 강해졌지만, 여전히 프롬프트와 도구 정의 설계에 따라 달라져요. 언제 행동/질문/확인/복구할지 프롬프트가 정의하지 않으면, 도구를 너무 일찍 호출하거나 불필요한 질문을 하거나 실패 호출을 반복할 수 있어요.

도구 호출 적극성(eagerness): 읽기 전용·저위험 동작은 높은 적극성이 잘 맞고, 데이터를 수정하거나 외부 효과를 일으키거나 정확한 식별자에 의존하는 도구는 낮은 적극성이 낫습니다.

도구 유형	기본 동작
읽기 전용·저위험 조회	의도와 필수 필드가 명확하면 호출
정확한 식별자가 있는 읽기 전용	조회 전에 식별자 확인
사용자에게 보이는 커뮤니케이션	보내기 전에 초안/요약
계정 변경	호출 전에 확인
구매·취소·결제	호출 전에 금액·대상·결과 확인
되돌릴 수 없거나 고영향 동작	명시적 확인 + 적절할 때 에스컬레이션 제안

## Tools
Use only the tools explicitly provided in the current tool list. Do not invent, assume, simulate, or rename tools.

For read-only tools:
- Call the tool when the user's intent is clear and all required fields are available.
- Do not ask for confirmation unless the lookup depends on a high-precision identifier or there is meaningful risk of using the wrong record.
- Ask a clarification question only if a required field is missing, ambiguous, or conflicting.

For write tools or external actions:
- Summarize the intended action before calling the tool.
- Include the key consequence, such as what will be changed, sent, canceled, ordered, or charged.
- Ask for confirmation.
- Do not call the tool until the user clearly confirms.

For exact identifiers:
- Treat order IDs, tracking numbers, account numbers, confirmation codes, phone numbers, and email addresses as high precision.
- Normalize only when the field type is clear.
- Confirm the final value before account-specific lookups, validation, or write actions.

After tool calls:
- Only say an action was completed after the tool call succeeds.
- If the tool fails, explain the failure briefly, avoid raw errors, and give the user a clear next step.

고위험 예시 — 사용자: "남은 잔액으로 내 카드를 결제해 줘." 나쁜 답: "카드를 결제했어요." 좋은 답: "확인 차 말씀드리면, 등록된 카드로 남은 잔액 $248.16을 결제할까요? 진행할까요?"

도구 실패 복구: 실패마다 다르게 대처하세요. 어떤 실패는 조용히 재시도하고, 어떤 실패는 사용자에게 명확화를 요청하거나 식별자를 고치거나 새 동작을 확인하게 하거나 대체 경로를 제안해야 합니다.

## Tool Failures
If a tool call fails:
1. Briefly explain what failed in user-friendly language.
2. Do not blame the user or expose raw tool errors.
3. If the failure may be due to an exact identifier, read back the value used and ask the user to correct it.
4. If the failure may be temporary, offer to retry once.
5. If the same failure happens repeatedly, offer an alternate path or escalation.
Do not repeatedly call the same tool with the same arguments after failure.
Do not ask for a different identifier until you have first checked whether the captured value was correct.

도구 가용성 동기화: 프롬프트가 실제로 없는 도구를 언급하거나 도구 목록이 프롬프트와 불일치하면, 모델이 도구 이름을 지어내거나 완료된 척할 수 있어요. 예: 프롬프트에 lookup_order를 언급했는데 실제 도구가 search_orders라면, 모델이 잘못된 이름을 부르거나 동작을 흉내낼 수 있어요.

## Tool Availability
Use only the tools that are explicitly provided in the current tool list.
Do not invent, assume, or simulate tools. If a tool is mentioned in the instructions but is not present in the tool list, treat it as unavailable.
If the user requests an action that requires an unavailable tool:
1. Do not pretend to complete the action.
2. Briefly explain that the tool is not available.
3. Offer the closest supported next step.
Only say an action was completed after the relevant tool call succeeds.

침묵·배경 오디오 처리

보이스 에이전트는 기본적으로 반응하곤 해요. 프로덕션에서는 침묵, 배경 소음, 대기 음악, TV 소리, 옆 대화 같은, 음성 응답이 필요 없는 오디오를 자주 듣게 됩니다. 조용히 듣고 있게 하려면 no-op 대기 도구를 쓰세요.

{
  "name": "wait_for_user",
  "description": "Call this when the latest audio does not need a spoken response, such as silence, background noise, hold music, TV audio, side conversation, or speech not addressed to the assistant. This tool helps end the turn without a spoken reply.",
  "parameters": { "type": "object", "properties": {}, "required": [] }
}

## Handling Silence and Background Noise
If the latest audio is silence, background noise, hold music, TV audio, side conversation, or speech not addressed to you, call `wait_for_user`.
Do not respond conversationally after calling this tool.
Do not say "I'm here," "I didn't catch that," "Take your time," or "Let me know when you're ready."
Resume normal responses only when the user clearly addresses you or asks for help.

이건 주소가 지정되지 않은 오디오용이지, 불명확한 사용자 요청용이 아니에요. 사용자가 분명히 어시스턴트에게 말하는데 내용이 이해 불가하면 명확화를 요청하세요.

메시지 채널을 의도적으로 쓰기

gpt-realtime-2는 commentary 채널에서 사용자에게 보이는 중간 메시지를, final 채널에서 최종 사용자 응답을 만들 수 있어요.

채널	사용자에게 보이나요?	용도
`commentary`	예	preamble과 도구 호출
`final`	예	최종 사용자 메시지

API 출력에서 이 구분은 response.done 이벤트로 표현되며, phase 값이 commentary인지 final_answer인지 알려줍니다. 이 필드로 각 단계를 다르게 처리할 수 있어요.

response.output[0].phase: "commentary"
response.output[1].phase: "final_answer"

불명확한 오디오 처리

모델은 자신 있게 이해할 수 있는 오디오에만 반응해야 해요. 오디오가 불명확하면 추측 대신 짧은 명확화 질문을 해야 합니다. 모델이 누락된 단어를 유추하거나, 도구를 호출하거나, 엔티티를 캡처하거나, preamble을 생성하거나, 사용자가 말했을 내용을 재구성하느라 숨은 추론 시간을 쓰지 못하게 하세요.

## Unclear Audio
- Only respond to clear audio or text.
- If the user's audio is not clear, ask for clarification using a short phrase such as "Sorry, could you repeat that clearly?"
- Don't repeat the same unclear-audio clarification twice.
- Treat audio as unclear if it is ambiguous, noisy, silent, unintelligible, partially cut off, or if you are unsure of the exact words the user said.
- Do not guess what the user meant from unclear audio.
- Do not reason when the audio is unclear.
- Do not provide a preamble or call tools in the commentary channel when the audio is unclear.

정확한 엔티티 캡처

주문 ID, 추적 번호, 이메일 주소, 확인 코드, 계정 번호, 클레임 번호, 티켓 ID, 지원 참조, 전화번호 같은 정확한 값은 많은 실시간 워크플로우의 핵심이에요. 음성 때문에 어려운데, 사용자는 빨리 말하고, 숫자를 다르게 묶고, 일부만 철자하고, 잡담을 넣고, 중간에 고치고, 비슷한 발음을 하죠. 한 자리만 틀려도 조회가 실패하거나 잘못된 계정을 가져올 수 있어요.

한 번에 하나의 엔티티 수집 — 여러 값이 필요한 워크플로우에서는 하나씩 수집해 필드가 섞이지 않게 하세요.

## Entity Collection Order
Collect required values one at a time.
- Ask for only the next missing value.
- Do not ask for multiple values in the same turn.
- Before asking, check whether the value was already provided earlier in the conversation or the session.
- If a possible value already exists, confirm it with the user before using it.
Do not call tools until the current value has been collected, validated, and confirmed.

철자로 말한 문자 처리:

## Spelled-Out Characters
When a user dictates an ID, code, or email character by character, treat the spoken sequence as one compact value. Preserve explicitly spoken separators like dash, dot, underscore, slash, or plus; otherwise do not add spaces or separators.
Examples:
- "A B C one two three" -> "ABC123"
- "B C dash nine eight seven" -> "BC-987"
- "J O H N at example dot com" -> "[email protected]"
Do not insert spaces between spelled-out characters unless the user explicitly says the value contains spaces.

말로 한 숫자 정규화:

## Spoken Number Handling
Convert spoken numbers into digits when collecting numeric identifiers.
Examples:
- "one two three four" -> "1234"
- "one twenty three" -> "123"
- "one nineteen" -> "119"
- "ninety nine eleven" -> "9911"
If multiple interpretations are plausible, ask the user to clarify before using the value.

도구 호출 전 정확한 식별자 확인 — 주문 ID, 추적 번호, 계정 번호 등은 고정밀 필드예요. 도구 호출에 쓰기 전에 확인하세요. 숫자 식별자는 한 자리씩 읽어 되돌려 주세요. 전체 숫자로 읽으면 오류가 숨을 수 있어요.

## Exact Identifier Confirmation
Before calling tools with high-precision identifiers:
- Confirm the final normalized value with the user.
- Read numeric identifiers back digit by digit.
- Do not use guessed, partial, or ambiguous values.
- If the user corrects the value, repeat the full corrected value before calling the tool.

이메일을 문자 단위로 확인:

## Email Confirmation
Email addresses must be captured exactly.
If the user says the email naturally without spelling it out, ask them to repeat it character by character.
When reading an email back, confirm the exact final email address.
Example: "Could you spell the email address character by character so I can make sure I have it exactly right?"

엔티티 수집 워크플로우 — 작업이 정확한 값을 요구하면 이를 사용하기 전에 수집·확인하세요:

## Entity Collection Workflow
1. Collect the next required value.
- Ask for only one missing value at a time. Do not ask for multiple exact values in the same turn.
- Before asking, check whether the value was already provided earlier in the conversation or session.
2. Normalize only what is clear.
- Convert clearly spoken digits or spelled-out characters into the expected format.
- Preserve explicit separators such as dashes, dots, underscores, slashes, and plus signs.
- Do not guess, infer, repair, or fill in unclear characters.
- If the value could be interpreted in more than one way, ask the user to repeat or clarify.
3. Confirm the final value.
- Read back the normalized value before using it. For numeric identifiers, confirm digit by digit. For email addresses, confirm character by character when precision matters. Wait for a clear confirmation.
4. Call the tool only after confirmation.
- Do not call lookup, account, messaging, payment, booking, or update tools with guessed, partial, ambiguous, or unconfirmed values.
5. Recover safely from corrections.
- If the user corrects any part of the value, update it, repeat the full corrected value, and ask for confirmation again.
Never call tools with guessed, partial, ambiguous, or unconfirmed exact values.

문자 그대로 지시 함정 피하기

gpt-realtime-2는 이전 모델보다 지시를 더 문자 그대로 따라요. must, only, never, always 같은 제약어를 조심하세요. 정말 필수일 때만 쓰고, 일반 강조로 쓰지 마세요. 과도한 하드 제약은 에이전트를 경직되고 지나치게 조심스럽게 만들 수 있어요. 정밀한 범위를 선호하세요.

좋은 범위: "사용자 데이터를 수정하는 쓰기 동작은 도구 호출 전에 확인을 요청하세요."
나쁜 범위: "무엇이든 하기 전에 항상 확인을 요청하세요." — 이러면 무해한 읽기 전용 조회에서도 불필요한 확인이 생깁니다.

일반 프롬프팅 권장:

명시적 지시를 암묵적 의도보다 선호.
진짜 경직이 필요하지 않으면 불필요한 제약어 피하기.
모순되는 지시 최소화.
겹치거나 경합하는 우선순위 지시에 주의.
점진적으로 테스트 — 작은 문구 변경이 큰 동작 변화를 만들 수 있어요.
이전 realtime 모델에서 마이그레이션할 때 일부 프롬프트는 재구성이 필요할 수 있어요.

언어·악센트를 따로 제어

언어와 악센트는 분리해 제어하세요. 악센트는 의도한 언어와 같지 않아요. 힌디어·스페인어·프랑스어·중국어 악센트로 영어를 말해도 영어 응답을 기대할 수 있어요. "Mirror the user", "Respond naturally in the user's language" 같은 광범위한 지시는 피하세요. 모델이 악센트나 채움말을 언어 전환 이유로 해석할 수 있어요.

영어 정책:

## Language
English is the default response language.
- Do not infer language from accent alone.
- Ignore short filler sounds, backchannels, and isolated foreign words for language detection.
- Only switch languages if the user explicitly asks or provides a substantive utterance in another language.
- If language confidence is low, ask a short clarification instead of guessing.
- Keep preambles, spoken bridges, tool-related messages, and final answers in the same language.
- Accent adaptation must not change the response language.

다국어 정책:

## Language
Default to English unless the user clearly uses another language.
Switch languages only when:
- the user explicitly asks to use another language;
- the user provides a substantive utterance in another language (a complete request, question, or correction, not just a greeting, name, address, filler word, or borrowed phrase).
Do not switch languages based on: accent; pronunciation; filler words; short backchannels; names; addresses; isolated foreign words.
If uncertain, ask: "Would you like me to continue in English or [LANGUAGE]?"

악센트 제어 — "Sound Australian." 같은 모호한 프롬프트 대신 대상 악센트, 안정되어야 할 특성, 말하기 속도·강세·prosody, 언어 선택에 영향을 줄지 여부를 지정하세요:

## Accent
Speak English with a light Australian accent.
- Keep the accent stable from the first word to the last.
- Use natural Australian vowel shaping, but keep speech easy to understand.
- Do not exaggerate the accent.
- Do not change response language based on the user's accent.

Custom Voices: 표준 음성으로 브랜드·악센트·캐릭터 요구를 확실히 맞추지 못할 때 쓰세요. 프롬프팅은 악센트·속도·전달을 조정할 수 있지만 음성 디자인을 완전히 대체하진 못해요. Custom Voices는 승인된 고객에게만 제공되며, 접근은 계정 팀에 문의하세요.

긴 세션에서 상태 유지

gpt-realtime-2의 128k 토큰 컨텍스트는 대략 밀도 높은 양방향 대화 1~2시간이라고 보면 돼요(도구 사용, 내부 추론, 주입된 기록에 따라 달라져요). 긴 컨텍스트에서는 무엇이 현재 정보이고, 무엇이 배경이고, 출처 충돌 시 무엇을 무시해야 하는지 모델이 알게 하는 게 성능에 좋아요. 구조를 쓰세요.

## Context
### Current State
- **Current task:** [current task]
- **Latest known state:** [current value]
- **Next safe step:** [what the assistant should do next]
### Authoritative Sources
- **Fact or record:** [fact or record]
- **Source:** [tool result / active policy / verified record]
- **Status:** current
### Historical or Background Sources
- **Older fact or record:** [older fact or record]
- **Source:** [prior conversation / older record / summary]
- **Status:** stale or background
- **Note:** Do not use for current decisions if it conflicts with a current source.
### Relevant Policy or Rules
- [decision rule or constraint]
### Other Context
- [potentially useful but non-authoritative background]

이전 realtime 모델에서 마이그레이션

프롬프트를 그냥 옮길 것이 아니라 동작 표면(behavior surface)으로 다루세요:

Codex나 강한 추론 모델로 최신 Realtime 프롬프팅 가이드 기준에 맞게 재구성.
reasoning effort를 기본값 대신 low로 설정 (더 깊은 계획이 필요한 워크플로우만 올림).
도구 이름·파라미터·enum·JSON 스키마 등을 구현과 일치하는지 감사.
오래된 예시 제거, 해피패스·모호성·중단·도구 호출·폴백 예시 추가.
마이그레이션 전후 대표 대화 비교, 기존 eval으로 회귀 확인.
최종 일관성 패스 — 하드 요구사항·기본값·도구 규칙·안전 규칙·폴백을 명확히 분리.
eval로 대표 실패를 살피며 반복.

Realtime 1.5 프롬프팅 가이드

gpt-realtime-1.5는 Realtime API의 음성↔음성 모델이고, 동일한 gpt-realtime 프롬프팅 가이드가 적용돼요. 이전 preview 모델보다 지시 따름, 도구 호출, 음성 품질, 전반적인 느낌이 강해져서, 체인 방식에서 진짜 실시간 경험으로 옮기기 실용적이 됐어요.

일반 팁

끊임없이 반복하세요: 작은 문구 변경이 동작을 좌우해요. (예: "inaudible"→"unintelligible"로 바꿔 잡음 입력 처리가 개선됨)
단락보다 불릿: 짧고 명확한 불릿이 긴 단락보다 잘 통해요.
예시로 안내: 모델은 샘플 문구를 가깝게 따라요.
정밀하게: 모호하거나 충돌하는 지시는 성능 저하로 이어져요.
언어 제어: 원치 않는 언어 전환이 보이면 대상 언어로 고정.
반복 줄이기: Variety 규칙을 추가해 로봇 같은 문구를 줄여요.
대문자로 강조: 핵심 규칙을 대문자로 쓰면 눈에 띄고 따르기 쉬워요.
비텍스트 규칙을 텍스트로: "IF x > 3 THEN ESCALATE"보다 "IF MORE THAN THREE FAILURES THEN ESCALATE"처럼 쓰세요.

프롬프트 구조

라벨이 붙은 섹션으로 정리하면 모델이 상황을 이해하고 턴 간 일관성을 유지하기 쉬워져요.

# Role & Objective        — you are and what "success" means
# Personality & Tone      — the voice and style to maintain
# Context                 — retrieved context, relevant info
# Reference Pronunciations — phonetic guides for tricky words
# Tools                   — names, usage rules, and preambles
# Instructions / Rules    — do's, don'ts, and approach
# Conversation Flow       — states, goals, and transitions
# Safety & Escalation     — fallback and handoff logic

Role & Objective

에이전트가 누구이고 "완료"가 무엇인지 정의해요. 명시적일수록 모델이 역할을 잘 따릅니다.

# Role & Objective
You are a Quebecois French-speaking customer service bot. Your task is to answer the user's question.

# Role & Objective
You are a high-energy game-show host guiding the caller to guess a secret number from 1 to 100 to win 1,000,000$.

Personality & Tone

gpt-realtime-1.5는 특정 성격·말투를 흉내낼 때 지시를 잘 따라요.

# Personality & Tone
## Personality
- Friendly, calm and approachable expert customer service assistant.
## Tone
- Warm, concise, confident, never fawning.
## Length
2–3 sentences per turn.

속도 지시: Realtime API의 speed 파라미터는 재생 속도만 바꾸지, 모델이 말을 짓는 방식은 안 바꿔요. 실제로 빠르게 들리게 하려면 말하기 속도를 안내하는 지시를 추가하세요. "Do not modify the content of your response, only increase speaking speed for the same response."

언어 제약 — 랜덤 언어 전환 방지:

## Language
- The conversation will be only in English.
- Do not respond in any other language even if the user asks.
- If the user speaks another language, politely explain that support is limited to English.

모델이 가르치는 유스케이스도 할 수 있어요: 설명(Explanations)은 영어로, 연습 대화(Conversation)는 프랑스어로 하는 등 code-switch가 커스텀 지시로 가능해요.

반복 줄이기 — 샘플 문구를 과하게 써서 로봇처럼 들리는 걸 방지:

## Variety
- Do not repeat the same sentence twice.
- Vary your responses so they don't sound robotic.

Reference Pronunciations

브랜드명·기술 용어·지명이 자주 틀릴 때 음성학적 힌트를 줍니다.

# Reference Pronunciations
- Pronounce "SQL" as "sequel."
- Pronounce "PostgreSQL" as "post-gress."
- Pronounce "Kyiv" as "KEE-iv."

영숫자 발음: 전화번호, 카드 번호, 2FA 코드, 주문 ID를 읽을 때 자리/문자가 뭉개질 수 있어요. 한 문자씩 구분자와 함께 말하게 하고, 확인하고, 수정 후 재확인하게 하세요.

# Instructions/Rules
- When reading numbers or codes, speak each character separately, separated by hyphens (e.g., 4-1-5).
- Repeat EXACTLY the provided number; do not omit any digits.

Instructions

GPT-4.1/GPT-5와 비슷하게, 지시가 충돌·모호·불명확하면 gpt-realtime-1.5도 성능이 나빠져요. GPT-5를 써서 모호성, 정의 누락, 충돌, 미기술 가정을 지적받는 Instructions Quality Prompt와 특정 실패 모드를 겨냥한 Prompt Optimization Meta Prompt를 제공합니다.

불명확 오디오 / 무응답 처리:

## Unclear audio
- Always respond in the same language the user is speaking in, if unintelligible.
- Only respond to clear audio or text.
- If the user's audio is not clear (e.g. ambiguous input/background noise/silent/unintelligible) or if you did not fully hear or understand the user, ask for clarification.

배경 음악/소리 제거:

## Instructions/Rules
- Do not include any sound effects or onomatopoeic expressions in your responses.

Tools

도구 선택: 프롬프트가 실제 tools 목록에 없는 도구를 언급하면 나쁜 응답으로 이어질 수 있어요. 프롬프트의 도구 이름, 시그니처, 설명이 실제 정의와 일치하고 서로 모순되지 않게 하세요.

도구 호출 preamble: 도구 호출과 동시에 짧은 오디오 응답을 주면 지연을 가리고 사용자 경험이 좋아져요.

# Tools
- Before any tool call, say one short line like "I'm checking that now." Then call the tool immediately.

도구 정의의 description에 샘플 preamble 문구를 넣어 더 잘 제어할 수도 있어요.

도구 호출 확인 생략: "When calling a tool, do not ask for any user confirmation. Be proactive." — 모델이 도구 호출 시 확인을 요구하면 이런 지시로 확인 루프를 없앱니다. 너무 성급하면 "proactive" 같은 강한 단어를 부드럽게 바꿔보세요.

도구 호출 성능: 도구 수가 늘면 언제 각 도구를 쓰고 안 쓰는지 명시적으로 안내하세요. 각 도구에 "Use when" / "Do NOT use when"을 달고, 도구 호출 시퀀스 지시도 추가할 수 있어요.

도구 수준 동작: 전역 규칙 대신 도구별로 프로액티브 / 확인 먼저 / preamble을 지정해요. 예: READ용 도구는 프로액티브하게, WRITE용 도구는 명시적 확인을 요구하도록.

# TOOLS
- For the tools marked PROACTIVE: do not ask for confirmation from the user and do not output a preamble.
- For the tools marked CONFIRMATION FIRST: always ask for confirmation to the user.
- For the tools marked PREAMBLES: Before any tool call, say one short line like "I'm checking that now." Then call the tool immediately.

도구 출력 포맷: "정확히 반복하세요"가 필요한 긴 문자열 출력은 분포 밖(out-of-distribution)일 수 있어요. raw string 대신 작고 명시적인 JSON envelope(response_text + require_repeat_verbatim 같은 플래그)로 감싸면 더 "평범한 도구 결과"처럼 보이고 신뢰도가 올라갑니다.

{
  "response_text": "I just sent you an email with the verification link. Please open it and click \"Confirm\".",
  "require_repeat_verbatim": true
}

Rephrase Supervisor Tool (Responder-Thinker 아키텍처): 실시간 모델이 responder(사용자에게 말함)이고 강한 텍스트 모델이 thinker(계획·정책 조회·SOP 완료)인 구성에서, 텍스트 답변이 그대로 음성에 어울리진 않아요. responder가 thinker의 텍스트를 짧고 자연스러운 음성 우선 답변으로 다시 표현하도록 안내하세요. 예: "Just finished checking that—your credit card balance is thirty-two million three hundred twenty-three thousand two hundred thirty-two dollars in your favor. Does that match what you expected?"

Common Tools: gpt-realtime-1.5는 다음 공통 도구에 잘 학습되어 있어요. 비슷한 동작이 필요하면 이름·시그니처·설명을 가깝게 유지해 신뢰도를 높이세요.

# answer(question: string)
Description: Call this when the customer asks a question that you don't have an answer to or asks to perform an action.

# escalate_to_human()
Description: Call this when a customer asks for escalation, or expresses dissatisfaction with the call.

# finish_session()
Description: Call this when a customer says they're done with the session. If it's ambiguous, confirm before calling.

Conversation Flow

대화를 명확하고 목표 중심의 단계로 나누면 모델이 각 단계에서 무엇을 해야 할지 정확히 알게 돼요. 각 단계에 목표(Goal), 응답 방법(How to respond), 다음 단계로 넘어가는 종료 기준(Exit when)을 정의하세요. 이러면 정체, 단계 생략, 앞서가기를 막을 수 있어요.

# Conversation Flow
## 1) Greeting
Goal: Set tone and invite the reason for calling.
Exit to Discovery: Caller states they are a customer and mentions an initial goal or symptom.
## 2) Discover
Goal: Classify the issue and capture minimal details.
Exit when: Intent and needed details are known.
## 3) Verify
Goal: Confirm identity and retrieve the account.
Exit when: Account ID is returned.
## 4) Diagnose
Goal: Decide root cause.
Exit when: Root cause known.
## 5) Resolve
Goal: Apply fix, credit, or appointment.
Exit when: A fix/credit/appointment has been applied and acknowledged.
## 6) Confirm/Close
Goal: Confirm outcome and end cleanly.
Exit when: Caller declines more help.

Sample Phrases: 모델이 따라야 할 스타일·간결함·말투의 "앵커 예시"예요. 다만 항상 같은 문구를 반복하지 않게 하세요.

# Sample Phrases
- Below are sample examples that you should use for inspiration. DO NOT ALWAYS USE THESE EXAMPLES, VARY YOUR RESPONSES.
Acknowledgements: "On it." "One moment." "Good question."
Clarifiers: "Do you want A or B?" "What's the deadline?"
Bridges: "Here's the quick plan." "Let's keep it simple."
Empathy (brief): "That's frustrating—let's fix it."
Closers: "Anything else before we wrap?" "Happy to help next time."

Advanced Conversation Flow: 복잡한 시나리오를 다루는 두 가지 패턴이 있어요.

Conversation Flow as State Machine — 대화를 상태와 전이를 인코딩한 JSON 구조로 정의. 코드로 저장되므로 버전 관리, diff, 확장이 쉬워요. 각 상태에 id, description, instructions, examples, transitions를 넣습니다.
Dynamic Conversation Flow via session.updates — 현재 상태에 맞춰 system prompt와 tool list를 실시간으로 갱신. 상태 종료 조건이 충족되면 session.update로 전이하며, 다음 단계에 필요한 프롬프트·도구로 교체해요. 모델의 인지 부하를 줄여 복잡한 작업을 다루기 쉽게 만듭니다.