Інтеграція AI: чат-боти, RAG, семантичний пошук, рекомендації
Більшість "AI-чат-ботів" на сайтах — це просто обгортка над GPT-4o з системним промптом "ти помічник компанії X". Без контексту реальних даних компанії. Користувач запитує про конкретний тариф — бот галюцинує ціну. Запитує про статус замовлення — отримує загальні фрази. Це не інтеграція AI, це дорогий FAQ.
RAG як основа корисного чат-бота
Retrieval-Augmented Generation — стандартний підхід, коли потрібно, щоб модель відповідала на основі реальних документів компанії. Схема: запит користувача → пошук релевантних фрагментів у векторній БД → вставка фрагментів у контекст → відповідь моделі.
Деталі реалізації, які визначають якість:
Chunking стратегія. Документ неможливо просто розбити на куски по 500 токенів. Якщо розрізати посередині абзацу, смисл втрачається. Рекурсивний text splitter з overlap 10–15% — мінімум. Для структурованих документів (контракти, інструкції) — семантичний сплітер по розділах.
Модель еmбеддингів. text-embedding-3-large від OpenAI або intfloat/multilingual-e5-large для російськомовного контенту. Якість пошуку напрямо залежить від моделі — різниця між ada-002 та e5-large на російському тексті відчутна.
Векторна БД. pgvector для проектів, де вже є PostgreSQL — ставиш розширення, додаєш колонку типу vector(1536), створюєш HNSW-індекс. Для великих обсягів (10M+ документів) — Qdrant або Weaviate. На проекті з базою знань з 80 000 статей підтримки pgvector з HNSW-індексом давав p95 пошуку в 12ms — цього достатньо.
Гібридний пошук. Тільки векторний пошук погано знаходить точні збіги (артикули, імена, абревіатури). Тільки повнотекстовий пошук не розуміє смисл. Комбінація через RRF (Reciprocal Rank Fusion): векторний пошук + BM25, результати змішуються. У Qdrant це називається sparse-dense hybrid search.
Reranking. Після первинного пошуку (top-20 кандидатів) прогоняємо через cross-encoder модель (cross-encoder/ms-marco-MiniLM-L-6-v2) для точного переранжування. Це додає 50–100ms, але значно покращує relevance.
Семантичний пошук на сайті
Пошук "червоні кросівки для бігу" повинен знайти товари з описом "червоні спортивні кеди для бігу", навіть якщо слова не збігаються. Звичайний LIKE-пошук це не умує.
Архітектура: при додаванні товару/статті автоматично генеруємо еmбеддинг та зберігаємо у pgvector. При пошуку — еmбеддимо запит, шукаємо найближчих сусідів за cosine similarity. Індекс HNSW на 100 000 векторів будується за 2–3 хвилини, займає ~400MB у пам'яті для 1536-мірних векторів.
Рекомендаційні системи
Колаборативна фільтрація ("користувачі, схожі на вас, купували X") вимагає історії взаємодій — мінімум декілька місяців даних. Для нового продукту працює content-based: еmбеддинг поточного переглядаємого товару → пошук подібних за векторною відстанню.
Гібридна модель: content-based для нових користувачів, колаборативна для тих, у кого є історія. Switching threshold — зазвичай після 10–20 взаємодій перемикаємось на колаборативну. LightFM умює об'єднувати обидва підходи в одній моделі.
Для e-commerce з реальним трафіком — A/B тестування рекомендацій обов'язково. CTR та conversion rate на рекомендовані товари — основні метрики, не accuracy моделі.
Стримінг відповідей
Користувач не повинен чекати, поки модель згенерує весь відповідь. Server-Sent Events для стримінгу токенів — стандарт. OpenAI SDK підтримує stream: true, повертає AsyncIterator. На фронтенді — Vercel AI SDK або самописний EventSource-обробник.
Типова помилка: стримити на фронтенд через WebSocket замість SSE. Для однонаправленого потоку SSE простіше та надійніше.
Оркестрація агентів
Простий чат-бот відповідає на запитання. Агент може виконувати дії: створити тікет, перевірити статус замовлення, забронювати час. LangChain або LangGraph для оркестрації ланцюгів викликів інструментів. Vercel AI SDK (useChat + tools) для Next.js-проектів — інтеграція в кілька рядків.
Головна складність агентів — надійність. Модель іноді викликає не той інструмент або передає невірні параметри. Валідація через Zod-схеми на вході кожного інструменту, structured outputs для детермінованого JSON.
Процес роботи
Починаємо з аудиту даних: що є, у якому форматі, наскільки актуально. Немає сенсу будувати RAG на застарілій документації. Прототип за 1–2 тижні з замірюванням метрик (retrieval precision, hallucination rate через LLM-as-judge). Потім ітерації по якості — chunking, модель еmбеддингів, reranking.
Моніторинг у production: LangSmith або Langfuse для трейсингу ланцюгів викликів, логування запитів для ручного аудиту якості.
Графік
RAG-чат-бот з індексацією існуючої бази знань: 3–6 тижнів. Семантичний пошук поверх існуючого каталогу: 2–4 тижні. Рекомендаційна система з A/B тестуванням: 6–10 тижнів. Мультиагентна система з інструментами та інтеграціями: від 8 тижнів.