AI-інтеграції

Що це

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

Якщо ви вже випустили одну LLM-функцію і вона працює "майже завжди", то ви вже знаєте: наступні десять відсотків — найскладніша частина. Саме тут ми вступаємо в роботу.

Дві форми проєктів

Форма перша — RAG поверх ваших даних. У вас є корпус (звернення підтримки, документація, контракти, транскрипти, база знань). Ви хочете чат або пошуковий інтерфейс, що відповідає на запити з цього корпусу і коректно відмовляється, коли не знає відповіді. Випускаємо конвеєр індексування, шар пошуку, інженерію промптів, оцінювання та інтерфейс.

Форма друга — LLM-агенти у вашому продукті. Ви хочете вбудованого в продукт агента, який бере вказівку користувача і зв'язує виклики інструментів, щоб її виконати. Проєктуємо поверхню інструментів, пишемо промпти, будуємо запобіжники й інтегруємо з вашим API. Випускали агентів, що планують, формують чернетки, аналізують та маршрутизують — завжди з явним слідом "що агент зробив і чому".

Стек

Для RAG: Postgres з pgvector для корпусів до 50 мільйонів документів, спеціалізовані векторні бази (Pinecone, Qdrant) — коли цю межу перетинаємо. Чанкінг з перекриттям, гібридний пошук (семантичний плюс ключові слова), реранкер зверху. LangChain або LlamaIndex — коли вони реально підходять, чистий Python — коли ні.

Для агентів: обираємо модель за рівнем довіри, який потрібен задачі. Дешеві моделі для некритичного видобутку даних, frontier-моделі для міркувань, дотреновані — для вузьких випадків з великим обсягом. OpenAI, Anthropic Claude і відкриті ваги — усі є в нашій ротації.

Для моніторингу: трасування OpenTelemetry з відредагованими промптами й токенами, дашборди вартості одного запиту і затримок p95/p99, а також конвеєр оцінювання, який запускається в CI на кожній зміні промпту чи моделі.

Як насправді виглядає "оцінювання з першого дня"

Більшість "AI-проєктів" завершується оцінкою якості на відчуттях. Ми відмовляємось випускати такий результат.

На третій день кожного проєкту просимо у вас п'ятдесят реальних запитань і відповіді, які дав би людина-експерт. Це стає еталонним набором оцінок. Кожна зміна промпту, кожна заміна моделі, кожне налаштування пошуку автоматично переоцінюється. Відстежуємо точність, повноту, відповідність джерелам і вартість — так само, як команда баз даних відстежує плани запитів.

Перезапустити оцінювання можете й самі. Скрипт ми вам передаємо.

Як ми ставимо стелі вартості

Вартість LLM — це інженерія, не фінанси. Виставляємо стелю на запит і місячну стелю на старті, а потім проєктуємо систему від них:

• Кешуємо ембедінги безстроково; кешуємо відповіді для запитів, що переважно читають.
• Беремо найдешевшу модель, що проходить планку оцінювання, — зазвичай на щабель нижче за frontier.
• Додаємо жорсткий запасний шлях до дешевшої або локальної моделі, коли досягаємо порога бюджету.

Скорочували рахунки за LLM на 60–80% на успадкованих системах без втрати якості. Це не магія — це уважність.

Чого ми не робимо

• Не тренуємо foundation-моделі. Якщо ваш проєкт цього потребує, вам потрібна дослідницька команда, а не ми.
• Не обіцяємо конкретних цифр якості, поки не побачимо ваші дані. Спочатку запускаємо тижневий базовий замір — і всі планують бюджет від реальних даних.
• Не випускаємо агентів без можливості простежити їхні дії. Якщо регулятор запитає "чому система зробила саме так 14 березня?", відповідь у вас буде.