Technical Context
Я регулярно бачу в рахунках клієнтів одну й ту саму картину: RAG-продукт «ніби працює», а вартість відповіді починає жити власним життям. Тому, коли мені показують списання рівня $0.00134 за запит, я не радію автоматично — я спочатку розкладаю, з чого це число склалося і чи можна його стабільно повторювати в продакшені.
У Perplexity API ключовий набір цеглин для RAG виглядає так: лінійка Sonar (моделі під search-augmented завдання), окремий Search API та дуже дешеві Embeddings API. За публічними ставками (актуальними для 2026) Sonar починається приблизно від $1 за 1M input tokens і $1 за 1M output tokens у базового Sonar, і сягає $3 input / $15 output у Pro-рівнів, де додаються сильніший пошук/контекст (до ~200k) та «дорогий» генеративний вихід.
Що мене як архітектора чіпляє: Perplexity у цій зв'язці намагається зробити найбільш витратне місце RAG (пошук релевантного контенту) більш передбачуваним за ціною. Search API тарифікується як $5 за 1K запитів за «сирі» веб-результати, і при цьому не нараховує токени. Це різко спрощує розрахунок retrieval-кроку, якщо ви розділяєте «пошук» і «синтез відповіді».
Окремо відзначу embeddings: для RAG це не дрібниця, а регулярний OPEX на індексацію та переіндексацію. У Perplexity ціни в районі $0.004–$0.05 за 1M tokens залежно від моделі та розмірності. У практичній архітектурі це означає, що я можу сміливо закладати часті оновлення вектора, не перетворюючи базу знань на «скляну вітрину, до якої страшно торкатися».
Історія про «у підписці дають $5 кредитів на API» звучить правдоподібно на рівні досвіду користувача, але в документації Perplexity підписки в першу чергу націлені на web/app-використання, а не на гарантовані API-квоти. У моїх проєктах я це трактую просто: для продакшену спираюся на pay-as-you-go та офіційні ліміти/тарифи, а будь-які «бонусні кредити» — приємний шум для пілота, не для фінансової моделі.
Business & Automation Impact
Якщо ви будуєте високонавантажений RAG, низька ціна запиту змінює не «красу юніта», а межі допустимої архітектури. При дорогому inference я змушений економити на кожному кроці: агресивно стискати контекст, різати кількість джерел, відмовлятися від переранжування, прибирати перевірки фактів. Коли запит дешевий, я можу дозволити собі те, що реально підвищує якість і знижує ризики.
У моїй практиці в Nahornyi AI Lab це найчастіше виливається у три патерни ІІ-автоматизації:
- Двоетапний retrieval: дешевий Search API/векторний пошук → потім rerank/фільтрація → потім генерація. Я плачу за пошук окремо і контролюю його частоту.
- Кешування на рівні «наміру»: коли запити схожі, я кешую не текст відповіді, а структуру знайдених джерел і параметри збірки контексту. Це зменшує і токени, і кількість search-викликів.
- Декомпозиція агента: замість одного «розумного» дорогого кроку роблю кілька дешевих і вимірюваних (класифікація запиту, вибір колекції, вилучення, перевірка цитат). Так впровадження ШІ стає керованим як звичайний софт.
Хто виграє? Команди, у яких багато запитів і зрозумілий KPI на вартість відповіді: підтримка, пресейл, внутрішній пошук по регламентах, моніторинг новин/згадувань, комплаєнс-чернетки. Хто програє? Ті, хто спробує «купити економію» замість інженерії: без спостережливості (tokens, latency, hit-rate кешу, частка порожнього retrieval) дешевий API легко перетворюється на дорогу невизначеність.
Я окремо проговорюю це із замовниками: низький тариф не скасовує архітектурних помилок. Можна спалити бюджет навіть при $1 за мільйон вхідних токенів, якщо ви на кожному запиті тягнете 200k контексту, не вмієте обрізати HTML, не прибираєте навігаційне сміття і не обмежуєте кількість джерел. Впровадження штучного інтелекту в таких системах — це насамперед дисципліна пайплайну, а вже потім вибір моделі.
Strategic Vision & Deep Dive
Мій неочевидний висновок щодо Perplexity API такий: цінність тут не тільки в «дешево», а в тому, що пошук стає продуктовим примітивом. Коли search дешевий і відокремлений від генерації, я можу проєктувати RAG як конвеєр з SLA, а не як магію LLM.
У проєктах Nahornyi AI Lab я бачу два напрямки, де це особливо сильно розкривається.
1) Економіка якості: платити за результат, а не за надію
Я все частіше рахую вартість не «за запит», а за коректну відповідь із джерелами. Якщо я додаю крок перевірки цитат (ще один виклик моделі) і цим знижую відсоток ескалацій у підтримку — загальна вартість володіння падає, навіть якщо токенів стало більше. З Perplexity, де базовий Sonar і embeddings коштують дешево, у мене з'являється простір для таких «страхувальних» кроків без нервових узгоджень бюджету.
2) Архітектура ІІ-рішень під навантаження: ліміти та передбачуваність
У проді мене цікавить не прайс-лист, а передбачуваність: rate limits, хвости затримок, деградація при піку, вартість worst-case. Дешеві моделі провокують зловживання: розробник перестає думати про контекст і робить «довгий промпт на всі випадки». Я в таких випадках закладаю жорсткі технічні контракти: ліміт токенів на етап, ліміт джерел, таймаути на retrieval, і обов'язкову телеметрію по кожному кроку. Це і є нормальна AI-архітектура, а не набір викликів API.
Якщо дивитися вперед, я очікую, що ринок RAG зміститься від «яка модель розумніша» до «який пайплайн краще вимірюється і дешевший в експлуатації». Hype буде навколо бенчмарків, а виграють ті, хто побудує інженерну систему: контроль контексту, кеш, A/B retrieval-стратегій, і безпечні фолбеки.
Пастка, в яку найпростіше потрапити: побачити $0.00134 і вирішити, що далі можна не рахувати. Я рахую завжди — і саме тому в мене виходять масштабовані ІІ рішення для бізнесу, а не демо, яке страшно вмикати під реальних користувачів.
Якщо ви хочете прикинути економіку вашого RAG і спроєктувати продакшен-пайплайн (пошук, embeddings, кеш, ліміти, спостережливість), я запрошую вас на коротку консультацію. Напишіть мені в Nahornyi AI Lab — з вами говоритиме особисто Вадим Нагорний, і ми розберемо, як зробити ІІ-автоматизацію так, щоб вона сходилася і за якістю, і за бюджетом.