Словник англійської мови для OpenAI Realtime API

OpenAI Realtime API дозволяє з низькою затримкою, двосторонні аудіо і текстові розмови з GPT-4o через постійне з’єднання WebSocket. Він використовується для створення голосових помічників, інструментів транскрипції в реальному часі і інтерактивних застосунків штучного інтелекту, де час відповіді вимірюється в мілісекундах. Якщо ви створюєте або інтегруєте програму за допомогою цього API, вам слід точніше повідомляти свою команду про події, аудіобуфери і налаштування сеансу. У цьому повідомленні описано словниковий запас, який найчастіше використовується у обговореннях з інженерних питань, документах з проектування і переглядах запитів на завантаження для проектів API часу реального.

Ключовий словник

** З’ єднання WebSocket ** Постійне, двостороннє з’ єднання мережі, яке використовується для зв’ язку з API реального часу. На відміну від HTTP- запитів, які не мають стану і є односторонніми, з’ єднання WebSocket залишається відкритим протягом сеансу, що дозволяє серверу відсилати події до клієнта у будь- який час.

• Приклад: « Відкрити з’ єднання WebSocket перед початком потоку звуку — якщо ви надсилаєте звук до встановлення сеансу, ви втратите декілька перших кадрів. » *

input_audio_buffer.append Подія на стороні клієнта, яка надсилає частину необроблених звукових даних до вхідного буфера сервера. Аудіо передається невеликими порціями, а не відсилається всім разом, що дозволяє обробку в реальному часі. Корисний вантаж — це звук PCM з кодуванням base64. Приклад: “Ми викликаємо input_audio_buffer.append кожні 100 мілісекунд з даними мікрофона — буфер накопичується доки модель не виявить кінець мови.”

response.create Подія клієнта, яка явно наказує моделі створити відповідь, використовується у режимі вручну визначеного повороту. Після надсилання цієї події модель обробляє накопичені дані з аудіо або тексту і починає потік відповіді.

• Приклад: « Після того, як користувач натисне кнопку « надіслати », випустити подію response.create — в ручному режимі модель чекає на цей сигнал, а не автоматично виявляє тишу. » *

** розпізнавання_поворотів ** Механізм, за допомогою якого API часу реального визначає, коли мовець закінчив говорити і модель має почати відповідати. Його можна встановити на серверній стороні VAD (Voice Activity Detection) — де API автоматично визначає тишу — або вручну, де клієнт контролює, коли закінчується перетворення.

• Приклад: « Перемкнути виявлення повороту на серверну сторону VAD для застосунку споживача — користувачі очікують, що помічник буде відповідати природно, коли вони припинять говорити, а не коли вони натисніть кнопку. »*

** подія виклику_ функції ** Подія, надіслана сервером, що вказує на те, що модель бажає викликати інструмент (функцію), який ви зареєстрували у сеансі. Ваш клієнт повинен обробляти цю подію, виконувати функцію локально і надсилати назад подію conversation.item.create з результатом.

• Приклад: « Подія function_call запускається, коли помічник вирішує пошукати обліковий запис користувача — обробляє його у слухачі повідомлень WebSocket і відсилає результат протягом двох секунд, інакше відповідь буде перервана. » *

** conversation. item. create ** Подія клієнта, яку використовують для введення повідомлення, наприклад, результату інструменту, системного повідомлення або повідомлення користувача, безпосередньо у контекст розмови. Це основний спосіб подачі структурованих даних назад до поточного сеансу. Приклад: “Після виконання вашої функції, надішліть conversation.item.create з виведенням функції — модель автоматично включить його в наступну відповідь.”

** session. update ** Подія клієнта, яка змінює налаштування активного сеансу — змінює системну команду, зареєстровані інструменти, голос або параметри виявлення поворотів — без роз’ єднання і повторного з’ єднання. Приклад: «Використовувати session.update для перемикання системного запиту, коли користувач змінює контекст — повторное з’ єднання скине історію розмов.»

відповідь.аудіо.дельта Подія, надіслана сервером, яка містить частину звукового виводу моделі під час його створення. Клієнти отримують поток цих дельт і відтворюють їх поступово, що створює низьку затримку, потокове аудіо.

• Приклад: « Буферизувати response.audio.delta шматки і почати відтворення негайно — не чекайте повної відповіді, інакше ви втратите відчуття реального часу. » *

Як використовувати цей словник

API обговорення в реальному часі часто зосереджені на затримці і надійності. Коли ваша команда говорить про аудіо конвеєр, вони описують поток від захоплення мікрофоном, через input_audio_buffer.append, до виявлення, до response.create, до відтворення response.audio.delta. Зрозумівши цей словник, ви зможете визначити, де саме відбувається затримка або помилка — наприклад, « затримка знаходиться між визначенням повороту і першою дельтою звуку, а не у нашому коді відтворення »

Виклик функції за допомогою API реального часу вводить синхронний крок у поток потокових даних. Команди обговорюють, як обробляти події function_call без блокування відтворення аудіо, як затримувати результати застарілих функцій і як управляти станом розмови через декілька викликів інструментів в один хід.

Приклад розмови

Джордан: Голосовий помічник перериває відповіді в середині речення. Де перерва? ** Riley: ** Перевірте, чи не було передчасно викликано response.cancel — іноді VAD неправильно сприймає фоновий шум як тишу. Хороший аргумент. Нам нужно переключить выявление поворотов на ручное? Спробуй в постановках. Скористайтеся session.update, щоб змінити режим без розриву з’ єднання.

Practice

1. Накресліть діаграму послідовності одного голосового повороту: мікрофон → input_audio_buffer.append → VAD → response.create → response.audio.delta → відтворення. Опишете кожен крок англійською мовою, використовуючи словник з цього повідомлення.
2. Напишіть короткий абзац, у якому поясните менеджеру продукту, який не має технічних знань, що означає « виявлення поворотів » і чому це важливо для користувача. Уникайте технічного жаргону — перекладайте його простою англійською.
3. Пояснити в коментарі перегляду коду, чому conversation.item.create має бути відправлено перед response.create при обробці результату виклику функції, і що станеться, якщо порядок буде змінено.

Національний гідрографічний інститут: Відповідь і відповіді

Для розробників, чия перша мова не є англійською, тонкощі технічного спілкування можуть бути особливо викликом. Це не просто переклад слів; це розуміння того, як ці слова використовуються в професійному контексті - немовлені очікування щодо співпраці, зворотного зв’язку і вирішення проблем, які формують щоденну роботу в інженерній команді. Розглянемо деякі типові сценарії, де точне формулювання робить усю різницю.

Уявіть, що ви надіслали запит на витяг, який містить зміни, спрямовані на поліпшення точності визначення поворотів у API реального часу. Під час перегляду коду ваш колега залишає коментар: « Це добре, але чи не могли б ми спробувати збільшити розмір буфера, щоб зменшити потенційні піки затримки, коли декілька користувачів говорять одночасно? » Просте слово « покращити точність » може не повністю передати зміст повідомлення. Ця фраза свідчить про розуміння того, * чому * ви внесли зміни — передбачаючи проблеми з продуктивністю, пов’ язані з одночасним використанням. Аналогічно, на каналі Slack, де обговорюється зневадження обрізання аудіо, ви можете почути, як хтось каже: « Давайте розглянемо, чи не обмежує клієнт аудіобуфер ». Це не просто запитання про проблему; це пропозиція певної області дослідження і потенційної причини. Використання фраз на кшталт «зменшити піки затримки» або «бути заблокованим» демонструє глибше залучення до технічних деталей і дозволяє більш цілеспрямоване обговорення.

Крім того, важливо створювати чіткі описи PR. Замість нечіткого резюме типу « Впроваджено визначення поворотів » ви можете написати: « Впроваджено поліпшену логіку визначення поворотів за допомогою динамічно змінюваного розміру буфера для оптимізації обробки звуку на основі рівнів активності користувача. Це має на меті зменшити піки затримки під час періодів високого одночасного використання і поліпшити загальну чутливість. “Деталь тут - посилання на «динамічно змінений розмір буфера» і явне затвердження мети зменшення затримки - показує, що ви продумали потенційні проблеми і активно їх вирішуєте. Крім того, програма надає цінний контекст для переглядачів, надаючи їм змогу швидко зрозуміти обсяг і мотиви ваших змін. Пам’ятайте, чітке спілкування будує довіру і сприяє плавнішому співробітництву в команді.

Нарешті, пам’ятайте про активний голос. Фрази типу “Буфер був відрегульований” звучать пасивно. Активне формулювання - “Ми відрегулювали буфер” - демонструє власність і відповідальність, що високо цінується в інженерних середовищах. Це про перехід від простого повідомлення про те, що сталося, до активної участі в розв’язанні.

Ось простий приклад, який показує, як встановити розмір звукового буфера за допомогою node-stream-receiver :

const receiver = require('node-stream-receiver');

const options = {
  port: 8080,
  buffers: [
    { id: 'audio', maxSize: 65536 } // Set buffer size to 65536 bytes (64KB)
  ]
};

const r = receiver(options);

console.log('Receiver started');