Підключення OpenAI чи Anthropic до продукту: вибір, промпт і контекст, на який ніхто не закладає бюджет

Питання «який провайдер - OpenAI чи Anthropic» лунає майже на кожному kickoff-дзвінку, ніби це найважливіше рішення проєкту. Рідко так буває. Обидва API роблять структуровані виводи, обидва роблять виклик інструментів/функцій, обидва стрімлять, а різниця, яка реально важлива - розмір контекстного вікна, ціна за токен, наскільки суворо модель дотримується схеми, як вона поводиться при неоднозначних інструкціях - вирішується тестуванням ваших реальних промптів на ваших реальних даних, а не таблицею бенчмарків.

Рішення, що реально формують білд, приймаються після цього: як промпт пишеться і версіонується як код, а не крутиться в playground і забувається, як відповідь валідується перед тим, як застосунок їй довіряє, і як ви керуєте контекстом, коли розмова, документ чи пакетна задача переростають те, що влазить в один виклик.

1. OpenAI проти Anthropic рідко є рішенням, що реально важить

Я обираю на основі задачі, а не лояльності до бренду: чия підтримка структурованих виводів суворіша для пайплайну, насиченого схемами, чиє контекстне вікно реально вміщує потрібний документ, який ціновий рівень витримує очікуваний обсяг викликів, і - недооцінене - чия поведінка при відмовах підходить кейсу, близькому до чутливої теми. Два різні провайдери можуть обидва «працювати» в демо і різко розійтись, коли реальні користувачі надішлють реальні крайні випадки.

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

2. Промпт-інжиніринг - це специфікація, і його тестують як таку

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

Структуровані виводи й виклик інструментів/функцій - це те, що взагалі робить промпт тестованим: замість оцінювання вільного тексту на око, я перевіряю, що JSON-payload відповідає схемі, а значення в ньому задовольняють бізнес-правила. Це і є реальний результат «промпт-інжинірингу» на реальному проєкті, а не вдалий абзац.

3. Керування контекстом: те, на що ніхто не закладає бюджет

Кожна LLM-інтеграція рано чи пізно зустрічає розмову, документ чи пакетну задачу, більшу за контекстне вікно, і те, що відбувається далі, вирішує, чи фіча лишиться дешевою і точною, чи стане повільною і почне галюцинувати. Наївне дописування кожного повідомлення в історію працює в демо, а потім тихо ламається: витрати ростуть з кожним ходом, затримка росте разом з ними, і в якийсь момент модель починає губити реальне питання під старими ходами.

Виправлення - це якийсь мікс з обрізання старих ходів, підсумовування того, що було, замість повторення дослівно, і вибірки лише релевантного зрізу через embeddings і векторну базу, коли джерело - документ, а не розмова. Мультимодальний вхід - зображення чи сторінка PDF - це просто ще один тип контексту, яким керують так само: він рахується проти того самого вікна і потребує тієї самої дисципліни щодо того, що реально там має бути.

Висновок: виклик API - найменша частина інтеграції

Підключення LLM до продукту здебільшого не про виклик моделі - це адаптер, що робить провайдера замінним, промпт, до якого ставляться як до протестованої специфікації, схема, що ловить некоректну відповідь до того, як вона дійде до користувача, і стратегія контексту, що продовжує працювати після першої легкої демо-розмови. Я будую все це навколо того з OpenAI чи Anthropic, що реально підходить під задачу. Напишіть через форму, що ви хочете, щоб LLM робив у вашому продукті, і я скажу, що насправді потрібно для інтеграції.