В одному тесті Airbnb користувач отримав потрібний результат за три-чотири проходи з GPT‑6 Astra замість понад двадцяти з іншими моделями. Йшлося про стратегічні документи та іншу роботу поза програмуванням. Цифра приваблива, але вона описує один досвід, а не гарантоване прискорення всієї компанії.
Кейс цікавий практичним питанням: коли дорожча модель виправдовує себе меншою кількістю переробок? Нижче — факти з анонсу та запропонована схема, за якою невелика команда може перевірити це на власних задачах.
Що Airbnb робить із моделями OpenAI
23 вересня OpenAI повідомила про розширення співпраці з Airbnb. Інженерні та продуктові команди отримують ширший доступ до моделей через OpenAI API й Amazon Bedrock. У компанії вже є внутрішній помічник для розробки та віддалені агенти на базі Codex і моделей OpenAI.
За описом партнерів, Astra допомагає шукати складні помилки, обговорювати архітектуру систем і розглядати інженерні підходи. Технічний директор Airbnb також заявив, що команди випускають приблизно на 80% більше функцій, ніж рік тому, та назвав моделі OpenAI частиною свого інструментарію.
Докладну внутрішню схему розподілу задач, бюджет і методику вимірювання анонс не розкриває. Тому наведені нижче правила вибору моделі — редакційна пропозиція для власного експерименту. Не варто приписувати їх Airbnb.
Як читати результати кейсу Airbnb
Показник «три-чотири проходи замість понад двадцяти» — опис одиничного тесту зі слів користувача. Річне зростання кількості функцій стосується роботи команд загалом. Жодна з цих метрик сама по собі не доводить, що саме Astra спричинила все покращення.
Зручно уявити дві команди. Перша швидко генерує код, але довго його перевіряє. Друга пише повільніше, зате рідше повертає зміни на доопрацювання. За кількістю створених рядків перша може виглядати продуктивнішою, а за часом до прийнятого результату — програвати. Для вашого тесту важливо заздалегідь вирішити, який результат справді має цінність.
Окремо записуйте час людини. Якщо відповідь моделі доводиться сорок хвилин переписувати, низька ціна запиту мало говорить про економію. І навпаки: довга відповідь не стає корисною лише тому, що в ній багато пунктів і впевнені формулювання.
Які задачі варто дати Astra на пробу
Для першого експерименту я б узяв кілька задач, на яких команда регулярно витрачає час на повторні спроби. Наприклад, помилку з неочевидною причиною, вибір між двома архітектурними рішеннями та документ із суперечливими вимогами. Для кожної потрібен критерій завершення, зрозумілий без оцінки «начебто непогано».
| Задача | Що перевіряти в результаті |
|---|---|
| Пошук помилки | Чи відтворено проблему та чи проходить перевірка після виправлення |
| Проєктування системи | Чи враховано задані обмеження, залежності й ціну підтримки |
| Стратегічний документ | Чи виявлено суперечності та чи можна за висновком ухвалити рішення |
| Типова дрібна правка | Чи дає дорожча модель помітну перевагу за часом і якістю |
Останній рядок потрібен як контроль. Якщо просту задачу стабільно закриває доступніша модель, немає сенсу автоматично переводити її на дорожчу. Порівняння тарифів молодших моделей є в нашому матеріалі про GPT‑6 Sol і Luna.
Скільки коштує спроба з Astra через API
У офіційному описі Astra стандартний тариф OpenAI API становить $10 за мільйон вхідних і $50 за мільйон вихідних токенів. Токени — одиниці, на які модель розбиває текст; вони не дорівнюють словам. Для кешування діють окремі ставки.
Умовний запит із 20 тисячами вхідних і п’ятьма тисячами оплачуваних вихідних токенів коштуватиме $0,45: $0,20 за вхід плюс $0,25 за вихід. Це розрахунок для заданих обсягів без кешу та додаткових інструментів. У реальному процесі кількість токенів і повторних викликів може змінюватися.
Fast mode заявлений як режим до двох разів швидшої обробки за подвійну стандартну ціну. Його має сенс оцінювати окремо: якщо задача виконується у фоні, швидкість відповіді може бути менш важливою за бюджет.
Модель також доступна через інші заявлені канали, зокрема ChatGPT у межах відповідних планів і квот. Перед використанням перевіряйте умови свого каналу: API-розрахунок не описує списання ліміту підписки в чаті.
Як порівняти моделі на задачах команди
У настановах із вибору моделі OpenAI радить експериментувати з моделями та налаштуваннями під конкретний процес. Документація з оцінювання результатів також пропонує будувати перевірки навколо реальних сценаріїв. Для невеликого пілоту можна почати так:
- Візьміть добірку завершених задач, для яких уже відомий прийнятний результат. Включіть типові й складні випадки.
- Підготуйте однакові вхідні матеріали та критерії для обох моделей. Зафіксуйте доступні інструменти й обмеження.
- Порахуйте проходи до прийняття, витрати API, час перевірки та кількість суттєвих помилок.
- Повторіть частину задач: один вдалий результат може випадково прикрасити картину.
- Перевірте, чи зберігається виграш на нових задачах, яких не було в початковій добірці.
Наприклад, для аналізу вимог заздалегідь складіть список відомих суперечностей. Перевіряльник має бачити, які модель знайшла, які пропустила, а які вигадала. Така таблиця корисніша за порівняння того, чия відповідь звучить переконливіше.
Як перетворити пілот на робочий процес
Після тесту сформулюйте короткі правила. Типові задачі йдуть до моделі, яка стабільно проходить перевірку з прийнятною ціною. Якщо вона не впоралася, передавайте складнішій моделі вихідні вимоги, результати попередніх спроб і конкретну причину невдачі.
Поставте межу кількості автоматичних повторів. Нескінченний діалог двох агентів може виглядати як активна робота, поки бюджет тихо зникає. Для змін у продукті залиште звичну перевірку людиною та наявні тести. Про організацію тривалих завдань окремо розповідаємо в матеріалі про OpenAI Agents API.
Найкорисніше запитання після тижня пілоту: скільки коштувала одна прийнята задача з урахуванням людського часу? Якщо відповідь покращилася, у вас є власний аргумент для масштабування. Самої цифри з кейсу Airbnb для цього замало.
