For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
기본 탐색 메뉴
Theme

Realtime 모델 프롬프팅

Realtime 음성 모델용 프롬프트를 설계하고 테스트하세요.

개발에 사용할 Realtime 모델을 선택하세요. GPT-Live를 사용한다면 GPT-Live 프롬프팅을 참고하세요.

gpt-realtime-2는 지연 시간이 짧은 음성-음성 변환 애플리케이션을 위한 OpenAI의 최첨단 음성 추론 모델입니다. 말하기 전에 추론할 수 있으며, 이전 실시간 모델보다 지시를 더 충실히 따르고 더 큰 컨텍스트 윈도우를 활용하며 도구를 더 정확하게 호출합니다.

이러한 성능 향상을 활용하려면 원하는 동작을 구체적으로 고려해 프롬프트를 설계하세요. 어시스턴트가 무엇을 언제 해야 하고 무엇을 피해야 하는지 알 수 있도록 역할과 책임, 판단이 필요한 시점, 도구 호출 방식, 가드레일을 명시하세요.

간단하게 시작하세요. 처음부터 지시를 너무 많이 넣지 마세요. 최소한의 프롬프트로 평가를 실행한 뒤 테스트에서 기대대로 동작하지 않은 부분에만 지시를 추가하세요.

모델 선택

모델적합한 상황프롬프팅 시 중점 사항
gpt-realtime-2

실시간 추론, 도구 사용, 지시 이행에서 최고의 성능이 필요할 때

추론 수준, 사전 안내, 도구 사용 정책, 엔터티 값을 정확히 수집하는 방식, 장시간 세션의 상태 관리를 조정하세요.

gpt-realtime-1.5추론 없이 빠르고 안정적으로 동작하는 음성-음성 변환 모델이 필요할 때

실시간 프롬프트의 기본 구조를 따르고 지연 시간에 민감한 동작을 테스트하세요.

Realtime 2.0 프롬프팅 가이드

음성 에이전트에 더 강력한 추론 능력, 적절한 도구 선택, 정확한 엔터티 처리 또는 장시간 세션의 상태 관리가 필요하면 gpt-realtime-2를 사용하세요. reasoning.effort: “low”로 시작해 기본 사전 안내 동작을 테스트하고, 쓰기 작업 전에 어떤 경우에 사용자 확인을 받아야 하는지 명확히 정하세요.

Realtime 2에서 달라진 점

Realtime 2용 프롬프트는 단순한 음성 봇을 전제로 작성하기보다 추론할 수 있는 음성 에이전트에 맞춰 작성하세요.

변경 사항 프롬프트에 반영할 점
추론 복잡한 작업에서는 모델이 말하거나 도구를 호출하기 전에 내부적으로 추론할 수 있게 하세요. 어색한 침묵이나 불필요한 군말을 피하려면 사전 안내를 활용하세요.
더 중요해진 프롬프트의 정확성 “도움이 되도록 하세요” 같은 포괄적인 지시 대신 언제 동작하고 무엇을 하며 어떤 경우에는 하지 않아야 하는지 조건, 동작, 예외를 명시하세요.
지시 충돌의 영향 증가 꼭 필요한 경우를 제외하고 always, never, only, must가 포함된 규칙 중 서로 겹치는 것을 제거하세요. 규칙이 충돌할 때의 우선순위를 정하세요.
도구 사용 방식의 세밀한 제어 즉시 실행할 때, 누락된 정보를 물어볼 때, 정확해야 하는 정보를 확인할 때, 실패 후 재시도할 때, 상위 담당자에게 이관할 때를 각각 지정하세요.
독립적으로 제어할 수 있는 사전 안내 모델은 시간이 걸리는 추론이나 도구 사용에 앞서 진행 상황을 짧게 말할 수 있습니다. 사전 안내를 언제, 얼마나 짧게 말하고 언제 생략해야 하는지 지정하세요.
확장된 컨텍스트 윈도우 gpt-realtime-2의 실시간 컨텍스트 윈도우가 32k 토큰에서 128k 토큰으로 늘어 장시간 세션과 큰 시스템 프롬프트에 더 적합합니다.

사전 안내는 숨겨진 추론 과정과 다릅니다. “지금 주문 내역을 확인해 볼게요”처럼 진행 상황을 짧게 말하는 것입니다. 모델에 비공개 추론 과정을 밝히라고 요청하지 마세요.

권장 프롬프트 구조

프롬프트를 짧은 섹션으로 나누고 각 섹션에 제목을 붙이세요. 모델이 필요한 지시를 빠르게 찾을 수 있어야 합니다.

# 역할과 목표

# 성격과 말투

# 언어

# 추론

# 메시지 채널

# 사전 안내

# 응답 길이

# 도구

# 불명확한 음성

# 엔터티 수집

# 긴 컨텍스트에서의 동작

# 이관

모든 사용 사례에 모든 섹션이 필요한 것은 아닙니다. 제품에 맞는 섹션을 추가하세요.

추론 수준 설정

gpt-realtime-2는 지연 시간을 더 허용하면 더 깊이 추론할 수 있습니다. 어시스턴트가 워크플로우를 수행하는 데 충분한 추론 능력을 확보할 수 있는 가장 낮은 수준을 사용하세요.

대부분의 프로덕션 음성 에이전트에서는 low로 시작하세요. 작업의 복잡도, 허용 가능한 지연 시간, 실패 비용에 따라 수준을 높이거나 낮추세요.

추론 수준 적합한 상황 예시
minimal 지연 시간을 최소화하는 것이 가장 중요하고 작업이 단순할 때 스마트 홈 명령, 타이머, 간단한 일정 확인
low 빠른 응답과 기본적인 추론이 모두 필요할 때 고객 지원, 주문 조회, 간단한 정책 질문
medium 여러 단계로 이루어진 작업을 추론해야 할 때 기술 지원, 진단, 복잡한 라우팅
high 더 깊은 추론이 성공률을 실질적으로 높일 때 높은 정확도가 필요한 워크플로우, 이관 여부 판단, 제약 조건이 있는 작업
xhigh 지연 시간과 비용이 늘더라도 최대한 깊이 추론할 가치가 있을 때 복잡한 계획 수립, 중대한 사안의 우선순위 판단, 결과의 영향이 큰 도구 오케스트레이션

API 설정과 함께 언제 어느 정도로 추론해야 하는지 프롬프트로 안내하세요.

## 추론

- 바로 답할 수 있는 질문, 간단한 조회, 짧은 확인에는 추론하지 말고 빠르게 응답하세요.
- 여러 단계가 필요한 작업, 도구 선택, 문제 해결, 이관 시에는 실행하기 전에 추론하세요.
- 사용자의 음성이 불명확하면 오래 추론하지 말고 다시 말해 달라고 요청하세요.

상황에 맞는 사전 안내

사전 안내는 음성 에이전트가 추론하거나 정보를 조회하거나 도구를 호출하는 동안 진행 상황을 짧게 말해 주는 기능입니다. 적절히 사용하면 사용자는 어시스턴트가 요청을 처리 중임을 알 수 있습니다. 잘못 사용하면 군말이 늘어 사용자가 더 오래 기다린다고 느낍니다.

gpt-realtime-2는 기본적으로 사전 안내를 생성합니다. 먼저 기본 동작을 테스트하세요. 제품에서 의도한 경험과 다르면 프롬프트에서 명시적으로 조정하세요.

사전 안내 생성 및 재생 타임라인

## 사전 안내

요청을 처리 중이라는 사실을 알려 주는 것이 사용자에게 도움이 될 때만 짧게 안내하세요.

### 사전 안내를 할 때

다음과 같은 경우 사전 안내를 하세요.

- 사용자가 기다려야 할 만큼 시간이 걸릴 수 있는 도구를 호출하기 직전입니다.
- 여러 단계에 걸쳐 요청을 검토해야 합니다.
- 기록, 이용 가능 여부, 계정 상태 또는 정책 세부 사항을 확인하고 있습니다.
- 이관이나 인계를 준비하고 있습니다.
- 아무 말도 하지 않으면 어시스턴트가 응답하지 않는 것처럼 느껴질 수 있습니다.

안내가 필요하면 본격적인 추론이나 도구 사용을 시작하기 직전에 말하세요.

### 사전 안내를 생략할 때

다음과 같은 경우 사전 안내를 하지 마세요.

- 질문에 곧바로 답할 수 있습니다.
- 사용자가 단순히 확인하거나 정정하거나 거절했습니다.
- 음성이 불명확해 다시 물어봐야 합니다.
- 마지막으로 들린 소리가 침묵, 배경 소음, 통화 대기 음악, TV 소리 또는 주변 사람들의 대화입니다.
- 도구 호출이 금방 끝나고 진행 상황을 알려도 사용자에게 도움이 되지 않습니다.

### 사전 안내의 표현

사전 안내를 할 때는 다음 원칙을 따르세요.

- 자연스럽고 차분하게 짧게 말하세요.
- 턴마다 표현을 바꾸세요.
- 내부 추론 대신 수행할 작업을 설명하세요.
- 군말은 생략하세요.

다음과 같은 표현은 피하세요.

- “한번 생각해 볼게요…”
- “음…”
- “처리하는 동안 잠시만요…”
- “이제 도구에 접근하겠습니다…”

### 사전 안내의 길이

짧은 문장 하나로 말하세요.

영향이 큰 작업을 수행하기 전에 사용자에게 설명할 필요가 있는 경우를 제외하고는 짧은 두 문장을 넘기지 마세요.

### 권장하는 표현

- “지금 주문 내역을 확인해 볼게요.”
- “예약 내용을 조회해 볼게요.”
- “변경하기 전에 먼저 확인해 볼게요.”
- “정책을 확인하고 다음 단계를 안내해 드릴게요.”
- “계정 정보를 불러와서 맞는 계정인지 확인해 볼게요.”

### 피해야 할 표현

- “잠깐 생각해 볼게요.”
- “요청을 처리하는 동안 기다려 주세요.”
- “이제 도구를 사용하겠습니다.”
- “흥미로운 질문이네요. 신중하게 추론해 보겠습니다.”

응답 길이 제어

gpt-realtime-2는 작업 유형별로 얼마나 상세하게 답해야 하는지 프롬프트에 지정했을 때 길이 지시를 가장 잘 따릅니다. 단순히 “간결하게 답하세요”라고 하기보다 상황별로 어느 정도가 간결한 답인지 정하세요. 직접적인 답변, 도구 결과, 문제 해결, 비교, 이관에는 각각 다른 응답 길이가 적합할 수 있습니다.

## 응답 길이

- 바로 답할 수 있는 질문에는 짧은 1~2문장으로 답하세요.
- 정보를 확인할 때는 한 번에 질문 하나만 하세요.
- 도구 결과는 먼저 요약하고, 이어서 사용자에게 도움이 될 다음 행동 하나만 안내하세요.
- 제품이나 옵션을 비교할 때는 주요 차이점, 각각의 장단점, 어떤 사용자에게 적합한지를 설명하세요.
- 문제를 해결할 때는 사용자가 전체 절차를 요청하지 않는 한 한 번에 한 단계씩 안내하세요.
- 이관할 때는 이관이 필요한 이유와 이후 절차를 간단히 설명하세요.

예시

사용자: 어떤 요금제를 선택하면 될까요?

어시스턴트: 비용을 가장 낮추려면 Basic을 선택하세요. 팀 권한과 통합 청구가 필요하다면 Pro가 적합합니다. 규정 준수 검토나 관리자 제어 기능이 중요하다면 Enterprise를 선택하세요.

도구 사용 방식 설계

gpt-realtime-2는 도구 호출 성능이 향상되었지만, 도구를 사용하는 방식은 여전히 프롬프트와 도구 명세의 설계에 달려 있습니다. 언제 실행하고, 질문하고, 확인하고, 실패를 복구해야 하는지 정하지 않으면 어시스턴트가 너무 일찍 도구를 호출하거나 불필요한 질문을 하거나 실패한 호출을 반복할 수 있습니다.

도구 호출의 적극성 설정

위험이 낮은 읽기 전용 작업에는 적극적인 호출이 적합합니다. 도구가 데이터를 수정하거나 외부에 영향을 주거나 정확한 식별자를 요구하는 경우에는 더 신중하게 호출하는 편이 좋습니다.

도구 유형 기본 동작
위험이 낮은 읽기 전용 조회 의도와 필수 필드 값이 명확하면 호출합니다.
정확한 식별자가 필요한 읽기 전용 조회 조회 전에 식별자를 확인합니다.
사용자에게 보이는 메시지 전송 보내기 전에 초안을 작성하거나 내용을 요약합니다.
계정 변경 호출 전에 확인을 받습니다.
구매, 취소, 결제 호출 전에 금액, 대상, 실행 결과를 확인합니다.
되돌릴 수 없거나 영향이 큰 작업 명시적으로 확인을 받고 필요한 경우 담당자 이관을 제안합니다.

읽기 작업과 쓰기 작업이 섞여 있다면 다음 지시를 기본으로 사용하고, 사용 사례에 맞게 조정하세요.

## 도구

현재 도구 목록에 명시적으로 제공된 도구만 사용하세요. 도구를 지어내거나 있다고 가정하거나 동작을 흉내 내거나 이름을 바꾸지 마세요.

읽기 전용 도구:

- 사용자의 의도가 명확하고 필수 필드 값이 모두 있으면 도구를 호출하세요.
- 조회에 정확한 식별자가 필요하거나 잘못된 기록을 사용할 위험이 상당한 경우에만 확인을 요청하세요.
- 필수 필드 값이 누락되었거나 모호하거나 서로 충돌할 때만 다시 물어보세요.

쓰기 도구 또는 외부에 영향을 주는 작업:

- 도구를 호출하기 전에 수행하려는 작업을 요약하세요.
- 무엇이 변경, 전송, 취소, 주문 또는 청구되는지 등 주요 결과를 포함하세요.
- 사용자에게 확인을 요청하세요.
- 사용자가 명확하게 동의하기 전에는 도구를 호출하지 마세요.

정확한 식별자:

- 주문 ID, 운송장 번호, 계정 번호, 확인 코드, 전화번호, 이메일 주소는 한 글자도 틀려서는 안 되는 값으로 취급하세요.
- 필드 유형이 명확할 때만 정규화하세요.
- 특정 계정에 대한 조회, 검증 또는 쓰기 작업 전에 최종 값을 확인받으세요.

도구 호출 후:

- 도구 호출이 성공한 후에만 작업을 완료했다고 말하세요.
- 호출이 실패하면 원본 오류 메시지를 노출하지 말고 무엇이 실패했는지 짧게 설명한 뒤 다음 단계를 분명하게 안내하세요.

위험이 큰 작업의 예시

사용자: 남은 잔액을 제 카드로 결제해 주세요.

나쁜 예시

어시스턴트: 카드로 결제했습니다.

좋은 예시

어시스턴트: 등록된 카드로 남은 잔액 $248.16을 결제하려고 합니다. 진행할까요?

도구 호출 실패 시 복구

도구 호출 실패도 대화의 일부입니다. 복구할 때는 무슨 일이 있었는지 설명하고 사용자가 다음에 무엇을 할 수 있는지 분명하게 안내하세요.

모든 실패를 똑같이 처리하지 마세요. 도구 유형, 실패 양상, 사용자에게 미치는 영향에 따라 복구 방식을 달리해야 합니다. 일부 실패는 별도 안내 없이 재시도하는 것이 적절합니다. 그 밖의 경우에는 사용자에게 설명을 요청하거나 식별자를 정정해 달라고 하거나, 새로운 작업에 대한 확인을 받거나 다른 방법을 선택하도록 안내해야 합니다.

## 도구 호출 실패

도구 호출이 실패하면 다음 순서로 대응하세요.

1. 무엇이 실패했는지 사용자가 이해하기 쉬운 말로 간단히 설명하세요.
2. 사용자를 탓하거나 도구에서 반환한 오류를 그대로 보여 주지 마세요.
3. 식별자가 정확하지 않아 실패했을 가능성이 있다면 사용한 값을 읽어 주고 틀린 부분을 정정해 달라고 하세요.
4. 일시적인 문제일 수 있다면 한 번 더 시도할지 물어보세요.
5. 같은 문제가 반복되면 다른 방법이나 담당자 이관을 제안하세요.

실패한 뒤 같은 인수로 같은 도구를 반복 호출하지 마세요.

받아 적은 값이 맞는지 먼저 확인한 뒤에만 다른 식별자를 요청하세요.

나쁜 예시

어시스턴트: 문제가 발생했어요.

좋은 예시

어시스턴트: O R D 하이픈 3 1 2 5 B 2 3으로는 일치하는 주문을 찾을 수 없어요. 제가 잘못 들은 부분이 있을까요?

프롬프트와 사용 가능한 도구 목록 일치시키기

Realtime 모델은 사용자 요청을 적극적으로 처리하려고 합니다. 프롬프트에 실제로 사용할 수 없는 도구가 언급되거나 도구 목록과 프롬프트가 일치하지 않으면, 모델이 도구 이름을 지어내거나 작업을 완료한 것처럼 응답할 수 있습니다.

예를 들어 프롬프트에는 lookup_order가 있지만 제공된 도구 이름이 search_orders라면, 모델이 잘못된 이름으로 호출하거나 작업을 수행한 것처럼 응답할 수 있습니다.

## 사용 가능한 도구

현재 도구 목록에 명시적으로 제공된 도구만 사용하세요.

도구를 지어내거나 있다고 가정하거나 동작을 흉내 내지 마세요. 지시에 언급된 도구라도 도구 목록에 없으면 사용할 수 없는 것으로 간주하세요.

사용자가 요청한 작업에 사용할 수 없는 도구가 필요하다면 다음과 같이 대응하세요.

1. 작업을 완료한 것처럼 말하지 마세요.
2. 해당 도구를 사용할 수 없다고 짧게 설명하세요.
3. 지원되는 방법 중 사용자의 요청에 가장 가까운 다음 단계를 제안하세요.

해당 도구 호출이 성공한 후에만 작업을 완료했다고 말하세요.

부록의 프롬프트 점검용 메타 프롬프트로 프로덕션 프롬프트에 모순된 지시, 누락된 도구, 상황이 조금만 달라져도 제대로 작동하지 않는 지시가 있는지 검토하세요.

침묵과 배경음 처리

음성 에이전트는 기본적으로 응답하려는 경향이 있습니다. 실제 환경에서는 침묵, 배경 소음, 통화 대기 음악, TV 소리, 주변 사람들의 대화처럼 음성으로 답할 필요가 없는 입력을 자주 받습니다.

어시스턴트가 말하지 않고 계속 들어야 할 때는 아무 작업도 수행하지 않는 대기 도구를 사용하세요. 이 도구를 사용하면 모델이 “듣고 있어요”나 “잘 못 들었어요”라고 말하는 대신, 말없이 턴을 마칠 수 있습니다.

도구 설계

{
  "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": []
  }
}

다음 프롬프트 지시를 함께 사용하세요.

## 침묵과 배경 소음 처리

마지막 오디오 입력이 침묵, 배경 소음, 통화 대기 음악, TV 소리, 주변 사람들의 대화 또는 어시스턴트에게 건넨 말이 아닌 발화라면 `wait_for_user`를 호출하세요.

이 도구를 호출한 뒤에는 말로 응답하지 마세요.

“듣고 있어요”, “잘 못 들었어요”, “천천히 하세요”, “준비되면 말씀해 주세요” 같은 말도 하지 마세요.

사용자가 분명히 어시스턴트에게 말을 걸거나 도움을 요청할 때만 다시 정상적으로 응답하세요.

이 방식은 어시스턴트를 향한 발화가 아닌 입력에 사용하세요. 사용자가 분명히 어시스턴트에게 말을 걸었지만 내용을 알아들을 수 없다면 다시 말해 달라고 요청하세요.

메시지 채널 구분하기

gpt-realtime-2는 commentary 채널에서 사용자에게 보이는 중간 메시지를, final 채널에서 사용자에게 전달할 최종 응답을 생성할 수 있습니다. 메시지가 표시되는 채널에 따라 원하는 동작이 다르다면 채널별 지시를 작성하세요.

채널 사용자에게 표시 용도
commentary 예 사전 안내 및 도구 호출
final 예 사용자에게 전달할 최종 메시지

예를 들어 도구 호출은 commentary 채널에서 이루어집니다. 도구를 사용하기 전이나 사용하는 동안 또는 사용한 후에 어시스턴트가 특정 내용을 말하도록 하려면 commentary 채널에서 언제 무엇을 해야 하는지 지정하세요.

commentary 채널에서 도구를 호출하기 전에 어떤 작업을 하는지 사용자에게 짧게 알려 주세요.

gpt-realtime-2는 한 턴에서 여러 단계에 걸쳐 응답을 출력할 수 있습니다. API 출력에서는 response.done 이벤트에 포함된 phase 값으로 해당 내용이 중간 안내인지 최종 답변인지 구분합니다.

애플리케이션에서는 이 필드를 사용해 단계별로 다르게 처리할 수 있습니다. 예를 들어 중간 안내는 짧은 진행 상황으로 재생하거나 표시하고, final_answer는 어시스턴트의 완성된 응답을 전달하는 데 사용할 수 있습니다.

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

불명확한 음성 처리

모델은 확실하게 알아들은 음성에 대해서만 동작해야 합니다. 음성이 불명확하면 추측하지 말고 짧은 질문으로 다시 확인해야 합니다.

불명확한 음성을 들었을 때 모델이 누락된 단어를 추측하거나, 도구를 호출하거나, 엔터티를 수집하거나, 사전 안내를 생성하지 않도록 하세요. 사용자가 무슨 말을 했을지 재구성하는 데 내부 추론 시간을 쓰지 않도록 하세요.

## 불명확한 음성

- 명확한 음성이나 텍스트에만 답하세요.
- 사용자의 음성이 불명확하면 “Sorry, could you repeat that clearly?”처럼 짧은 영어 문장으로 다시 말해 달라고 하세요.
- 음성이 불명확할 때 같은 확인 문구를 두 번 반복하지 마세요.
- 입력이 모호하거나, 잡음이 있거나, 아무 소리도 없거나, 알아들을 수 없거나, 일부가 끊겼거나, 사용자가 말한 단어가 정확히 무엇인지 확신하기 어렵다면 음성이 불명확한 것으로 판단하세요.
- 불명확한 음성만으로 사용자의 의도를 추측하지 마세요.
- 음성이 불명확할 때는 추론하지 마세요.
- 음성이 불명확할 때는 commentary 채널에서 사전 안내를 하거나 도구를 호출하지 마세요.

예시

사용자 음성: “주문 조회해 주세요. 번호는 삼 일…” [중간에 끊김]

나쁜 예시

어시스턴트: 지금 주문 번호 31을 조회해 볼게요.

좋은 예시

어시스턴트: 주문 번호가 일부만 들렸어요. 한 자리씩 다시 말씀해 주시겠어요?

엔터티 값 정확히 수집하기

많은 실시간 워크플로우에서는 주문 ID, 운송장 번호, 이메일 주소, 확인 코드, 계정 번호, 청구 번호, 티켓 ID, 지원 문의 번호, 전화번호 등의 값이 정확해야 합니다.

음성으로는 이런 값을 정확히 수집하기가 어렵습니다. 사용자는 빠르게 말하거나, 숫자를 여러 방식으로 묶어 읽거나, 값의 일부만 한 글자씩 불러 주거나, 군말을 섞거나, 말하는 도중에 정정하기도 합니다. 발음이 비슷한 문자를 혼동하기도 쉽습니다. 숫자 하나만 틀려도 조회에 실패하거나 다른 계정을 불러올 수 있습니다.

엔터티 값은 신중하게 수집하세요. 한 번에 하나의 값을 받고, 명확한 부분만 정규화하세요. 정확해야 하는 값은 도구 호출 전에 확인하고, 사용자가 어느 부분을 정정하더라도 이를 반영할 수 있도록 하세요.

한 번에 하나의 엔터티 수집하기

워크플로우에 여러 값이 필요하다면 하나씩 수집하세요. 특히 음성 대화에서 서로 다른 필드의 값이 뒤섞이는 것을 막을 수 있습니다.

## 엔터티 수집 순서

필수 값은 한 번에 하나씩 수집하세요.

- 아직 받지 못한 값 중 다음에 필요한 값 하나만 요청하세요.
- 한 턴에 여러 값을 요청하지 마세요.
- 물어보기 전에 이번 대화나 세션에서 사용자가 이미 알려 준 값인지 확인하세요.
- 사용할 만한 값이 이미 있다면 사용하기 전에 사용자에게 확인받으세요.

예시:

“앞서 알려 주신 운송장 번호 ABC-54321이 있어요. 이 번호로 조회할까요, 아니면 다른 운송장 번호가 있나요?”

현재 필요한 값을 수집하고 유효성을 검증한 뒤 사용자에게 확인받기 전까지는 도구를 호출하지 마세요.

한 글자씩 불러 주는 값 처리하기

사용자가 ID, 코드, 이름, 이메일 주소를 한 글자씩 불러 줄 때 다음 지시를 사용하세요. 소리 내어 읽은 형태는 입력이며 최종 값으로 변환해야 합니다.

## 한 글자씩 불러 주는 값

사용자가 ID, 코드 또는 이메일 주소를 한 글자씩 불러 주면 이어 붙여 하나의 값으로 처리하세요. 하이픈, 점, 밑줄, 슬래시, 더하기 기호처럼 사용자가 명시적으로 말한 구분자는 유지하세요. 그 밖에는 공백이나 구분자를 추가하지 마세요.

예시:

- “에이 비 씨 일 이 삼” -> “ABC123”
- “비 씨 하이픈 구 팔 칠” -> “BC-987”
- “제이 오 에이치 엔 골뱅이 이그잼플 점 컴” -> “john@example.com”

사용자가 값에 공백이 있다고 명시적으로 말한 경우에만 글자 사이에 공백을 넣으세요.

음성으로 입력된 숫자 정규화하기

숫자 식별자를 말할 때 사용자는 한 자리씩 읽거나 여러 자리를 묶어 읽거나 일반적인 수 읽기 방식을 사용할 수 있습니다. 필드에 연속된 숫자 값 하나가 필요하다면 명확하게 들린 수를 숫자로 변환하세요.

## 말로 읽은 숫자 처리

숫자 식별자를 수집할 때는 말로 읽은 수를 숫자로 변환하세요.

예시:

- “일 이 삼 사” -> “1234”
- “일 이십삼” -> “123”
- “일 십구” -> “119”
- “구십구 십일” -> “9911”
- “구천구백십일” -> “9911”

여러 해석이 가능하면 값을 사용하기 전에 사용자에게 다시 물어보세요.

예시:

“119인지 1-19인지 정확히 못 들었어요. 한 자리씩 다시 불러 주시겠어요?”

도구 호출 전에 식별자 확인하기

주문 ID, 운송장 번호, 계정 번호, 청구 번호, 확인 코드와 같은 식별자는 한 글자도 틀려서는 안 되는 필드입니다. 도구 호출에 사용하기 전에 확인하세요.

숫자 식별자는 한 자리씩 다시 읽어 주세요. 전체를 하나의 수로 읽으면 오류를 알아차리기 어렵습니다.

예시

어시스턴트: 제가 들은 번호는 8… 3… 5… 2… 1입니다. 맞나요?

사용자가 문자나 숫자 하나를 정정하면 도구를 호출하기 전에 수정된 값 전체를 다시 읽으세요.

예시

어시스턴트: 네, 8… 3… 5… 7… 1로 수정했어요. 맞나요?

## 식별자가 정확한지 확인하기

정확한 식별자가 필요한 도구를 호출하기 전에 다음을 지키세요.

- 정규화한 최종 값이 맞는지 사용자에게 확인받으세요.
- 숫자 식별자는 한 자리씩 다시 읽어 주세요.
- 추측한 값, 일부만 들은 값, 모호한 값은 사용하지 마세요.
- 사용자가 값을 정정하면 도구를 호출하기 전에 수정된 값 전체를 다시 읽어 주세요.

이메일 주소 한 글자씩 확인하기

이메일 주소는 정확히 수집해야 하는 값입니다. 마침표, 하이픈, 밑줄, 연속으로 나오는 같은 글자, 발음이 비슷한 이름 때문에 계정 조회에 실패하거나 잘못된 주소로 메시지가 전송될 수 있습니다.

사용자에게 이메일 주소를 한 글자씩 불러 달라고 요청하세요.

어시스턴트: 정확히 받아 적을 수 있도록 이메일 주소를 한 글자씩 불러 주시겠어요?

다시 읽어 줄 때는 최종 주소가 정확한지 확인하세요.

어시스턴트: 씨, 에이치, 이, 엔, 골뱅이 이그잼플 점 컴, 맞나요?

## 이메일 주소 확인

이메일 주소는 정확하게 받아 적어야 합니다.

사용자가 이메일 주소를 한 글자씩 불러 주지 않고 이어서 말하면 한 글자씩 다시 불러 달라고 하세요.

예시:

“정확히 받아 적을 수 있도록 이메일 주소를 한 글자씩 불러 주시겠어요?”

받아 적은 주소를 다시 읽어 주고 최종 이메일 주소가 정확한지 확인하세요.

예시:

“씨, 에이치, 이, 엔, 골뱅이 이그잼플 점 컴, 맞나요?”

엔터티 수집 워크플로우

지시가 문자 그대로 해석될 때의 함정 피하기

gpt-realtime-2는 이전 실시간 모델보다 지시를 더 문자 그대로 따릅니다. 이전 모델에서 잘 작동했던 프롬프트도 조정이 필요할 수 있습니다.

정확한 표현을 사용하세요. 모델은 개발자가 의도한 전반적인 동작보다 지시에 쓰인 문구를 우선할 수 있습니다. 지나치게 포괄적이거나 엄격한 규칙은 예상치 못한 방식으로 어시스턴트의 동작을 좌우할 수 있습니다. 여러 규칙이 겹칠 때 특히 그렇습니다.

must, only, never, always처럼 제약을 나타내는 단어는 신중하게 사용하세요. 단순히 강조하려는 경우가 아니라 해당 동작이 꼭 필요한 경우에만 사용하세요. 엄격한 제약을 남용하면 어시스턴트가 경직되거나 지나치게 조심스러워져 합리적인 예외도 처리하기 어려울 수 있습니다.

적용 범위를 구체적으로 지정한 예시

사용자 데이터를 수정하는 쓰기 작업에서는 도구를 호출하기 전에 사용자에게 확인받으세요.

피해야 할 포괄적인 지시

어떤 작업이든 시작하기 전에 항상 확인받으세요.

두 번째 지시를 사용하면 주문 상태 확인, 예약 가능 여부 조회, 계정 정보 열람처럼 위험이 없는 읽기 전용 조회 전에도 불필요하게 확인을 요청할 수 있습니다.

문자 그대로 해석한 예시

프롬프팅에 관한 일반 권장 사항

  • 의도를 암시하기보다 지시를 명시하세요.
  • 동작을 엄격하게 제한해야 하는 경우에만 제약을 나타내는 단어를 사용하세요.
  • 서로 모순되는 지시를 최소화하세요.
  • 우선순위 지시를 여러 겹으로 두거나 서로 경쟁하게 할 때는 주의하세요.
  • 프롬프트를 조금씩 바꾸며 테스트하세요. 작은 표현 차이로 동작이 크게 달라질 수 있습니다.
  • 이전 실시간 모델에서 마이그레이션할 때는 최상의 결과를 위해 일부 프롬프트의 구조를 바꿔야 할 수 있습니다.

언어와 억양을 별도로 제어하기

언어와 억양은 별도로 제어해야 합니다.

사용자의 억양만으로 원하는 응답 언어를 알 수는 없습니다. 힌디어, 스페인어, 프랑스어, 표준 중국어 억양으로 영어를 말하는 사용자도 영어 답변을 기대할 수 있습니다.

다음과 같이 포괄적인 언어 지시는 피하세요.

사용자를 따라 하세요.
사용자의 언어로 자연스럽게 답하세요.
적절한 경우 언어를 바꾸세요.
현지인처럼 말하세요.
사용자의 억양에 맞추세요.

이런 지시는 범위가 너무 넓습니다. 모델이 억양, 군말, 짧은 맞장구, 간혹 섞인 외국어 단어를 언어 전환의 근거로 해석할 수 있습니다.

영어 응답 정책

## 언어

기본 응답 언어는 영어입니다.

- 억양만으로 언어를 추정하지 마세요.
- 언어를 판단할 때 짧은 추임새나 맞장구, 간혹 섞인 외국어 단어는 무시하세요.
- 사용자가 명시적으로 요청하거나 다른 언어로 의미가 온전한 발화를 한 경우에만 언어를 전환하세요.
- 어떤 언어인지 확신하기 어렵다면 추측하지 말고 짧게 물어보세요.
- 사전 안내, 대화를 이어 주는 말, 도구 관련 메시지, 최종 답변에는 모두 같은 언어를 사용하세요.
- 억양을 조정하더라도 응답 언어는 바꾸지 마세요.

다국어 응답 정책

## 언어

사용자가 다른 언어를 사용한다는 점이 분명하지 않으면 기본적으로 영어로 답하세요.

다음 경우에만 언어를 전환하세요.

- 사용자가 다른 언어를 사용해 달라고 명시적으로 요청합니다.
- 사용자가 다른 언어로 의미가 온전한 발화를 합니다. 이는 그 언어로 요청이나 질문을 끝까지 말하거나 내용을 정정하는 경우를 뜻합니다. 단순한 인사, 이름, 주소, 추임새 또는 차용 표현만으로는 충분하지 않습니다.

다음만을 근거로 언어를 바꾸지 마세요.

- 억양
- 발음
- 추임새
- 짧은 맞장구
- 이름
- 주소
- 간혹 섞인 외국어 단어

확실하지 않으면 이렇게 물어보세요.

“영어로 계속할까요, 아니면 [LANGUAGE]로 계속할까요?”

억양 제어

gpt-realtime-2는 억양에 관한 지시를 더 충실히 따를 수 있습니다. 다만 억양 지시가 모호하면 말하는 도중 억양이 달라지거나 의도치 않게 언어가 바뀔 수 있습니다.

억양을 제어하는 프롬프트에는 다음 사항을 명시하는 것이 가장 효과적입니다.

  • 목표 억양
  • 일관되게 유지해야 하는 특성
  • 원하는 말의 속도, 강세, 운율
  • 억양 조정이 언어 선택에 영향을 주어야 하는지 여부

다음과 같은 지시 대신

호주 사람처럼 말하세요.

이렇게 작성하세요.

## 억양

가벼운 호주식 억양으로 영어를 말하세요.

- 첫 단어부터 마지막 단어까지 억양을 일관되게 유지하세요.
- 자연스러운 호주식 모음 발음을 사용하되 알아듣기 쉽게 말하세요.
- 억양을 과장하지 마세요.
- 사용자의 억양에 따라 응답 언어를 바꾸지 마세요.

맞춤 음성

기본 음성으로 브랜드, 억양, 캐릭터 요구 사항을 일관되게 충족하기 어려우면 맞춤 음성을 사용하세요.

프롬프트로 억양, 속도, 말하는 방식을 조절할 수 있지만 음성 설계를 완전히 대체할 수는 없습니다. 브랜드 고유의 목소리를 일관되게 유지하거나 특정 억양을 충실하게 재현해야 한다면 맞춤 음성을 고려하세요.

맞춤 음성은 승인된 고객만 사용할 수 있습니다. 사용 권한은 계정 담당 팀에 문의하세요.

장시간 세션에서 상태 유지하기

gpt-realtime-2는 실시간 컨텍스트 윈도우가 32k 토큰에서 128k 토큰으로 늘어 장시간 세션에 더 적합합니다. 양쪽이 쉴 새 없이 주고받는 대화라면 128k 토큰은 대략 1~2시간 분량의 원본 오디오 컨텍스트에 해당합니다. 실제 분량은 도구 사용, 내부 추론, 삽입된 레코드 등 세션의 세부 조건에 따라 달라집니다.

긴 컨텍스트를 사용하는 경우 gpt-realtime-2는 현재 유효한 정보와 배경 정보를 구분하고, 출처가 충돌할 때 어떤 정보를 무시해야 하는지 알 수 있을 때 가장 잘 동작합니다. 원본 대화 기록이나 대량의 컨텍스트를 그대로 넣고 모델이 출처의 우선순위를 알아서 추론하기를 기대하지 마세요. 정보를 구조화하세요.

조회한 레코드, 이전 대화 기록, 정책, 요약, 계정 메모, 배경 문서 등 많은 컨텍스트로 세션을 시작할 때는 일정한 구조에 맞춰 제공하세요.

이전 실시간 모델에서 마이그레이션하기

이전 실시간 모델에서 마이그레이션할 때는 프롬프트가 모델의 동작을 결정한다는 점을 고려하세요. 텍스트를 그대로 옮기는 것만으로는 충분하지 않습니다.

  1. Codex 또는 성능이 우수한 추론 모델을 사용해 최신 Realtime 프롬프팅 지침에 맞춰 프롬프트를 재구성하세요. 권장 방식에 따라 마이그레이션할 수 있도록 이 가이드의 링크를 포함하세요.
  2. 추론 수준을 기본값 대신 low로 설정하세요. 더 깊이 계획해야 하는 워크플로우에서만 수준을 높이세요.
  3. 도구 이름, 매개변수, 열거형, JSON 스키마, 기타 설정이 의도한 구현과 일치하는지 점검하세요.
  4. 오래된 예시를 제거하세요. 정상 처리, 모호한 입력, 대화 중단, 도구 호출, 대체 동작에 대한 짧은 예시를 추가하세요.
  5. 마이그레이션 전후의 대표 대화를 비교하세요. 기존 평가로 성능 저하 여부를 확인하고 의도한 동작 변경 사항을 문서화하세요.
  6. 마지막으로 일관성을 점검하세요. 프롬프트에서 필수 요구 사항, 기본 동작, 도구 규칙, 안전 규칙, 대체 동작을 명확히 구분했는지 확인하세요.
  7. 평가를 실행하고 대표적인 실패 사례를 살펴보세요. 목표한 동작이 안정적으로 나타날 때까지 프롬프트를 반복해서 개선하세요.

다음 단계

GPT-Live를 사용하는 경우

Realtime을 사용하는 경우