Розробка AI-системи конверсаційного пошуку з контекстним розумінням

Що таке конверсаційний пошук?

Звичайний пошук — stateless: кожен запит незалежний. Conversational Search запам'ятовує контекст діалогу: «Покажи протоколи нарад» → «А за минулий квартал?» → «Тільки ті, де згадується Іванов» — система розуміє, що кожен наступний запит уточнює попередній, не вимагаючи повторювати весь контекст. Результат — у 7 разів швидша навігація корпоративною базою знань. В одному з наших проєктів для юридичної компанії (120 юристів, 80 000 документів) до впровадження пошук прецеденту займав 18 хвилин, після — 2,5 хвилини. 78% завдань вирішуються без виходу з діалогу. Досвід — 5 років у AI-рішеннях, 40+ проєктів, сертифіковані інженери.

Співробітники витрачають в середньому 2–3 години на день на пошук інформації. Наша система скорочує цей час на 60%, що дає пряму економію операційних витрат. Переконайтеся самі — запросіть демо на ваших даних.

Які проблеми вирішує конверсаційний пошук?

Неоднозначні уточнюючі запити. Запит «А за минулий квартал?» безглуздий без контексту. Ми застосовуємо LLM-rewriting: перетворюємо фразу в standalone-запит зі збереженням усіх фільтрів.

Довгі сесії та контекстне вікно. Історія діалогу не вміщається в context window. Рішення — ієрархічне стиснення: старі turn'и стискаються в резюме сесії. Це економить до 70% токенів.

Відсутність персоналізації. Різні відділи шукають по-різному. Ми налаштовуємо системний промпт під роль: lawyer, HR, engineer.

Як ми будуємо конверсаційний пошук: ключові техніки

Query Rewriting

Головна інженерна проблема conversational search — ambiguous follow-up queries. Запит «А за минулий квартал?» безглуздий без попереднього контексту. Потрібно переформулювати його в standalone-запит перед пошуком.

from langchain_openai import ChatOpenAI
from langchain_core.messages import HumanMessage, AIMessage
from dataclasses import dataclass, field

@dataclass
class ConversationState:
    session_id: str
    history: list = field(default_factory=list)  # [(query, answer), ...]
    last_entities: list[str] = field(default_factory=list)
    last_time_range: tuple = field(default_factory=tuple)

class ConversationalSearchEngine:
    REWRITE_PROMPT = """Ти — система переформулювання запитів.
Перетвори уточнюючий запит на повний самодостатній запит на основі історії діалогу.

Історія:
{history}

Поточний запит користувача: {query}

Правила:
- Якщо запит самодостатній — поверни його без змін
- Якщо містить "це", "там", "той же", "ще раз" — розшифруй з контексту
- Збережи всі обмеження з попередніх запитів, якщо новий їх не знімає
- Поверни ТІЛЬКИ переформульований запит, без пояснень"""

    def __init__(self, search_engine, llm: ChatOpenAI):
        self.search = search_engine
        self.llm = llm

    def search_with_context(
        self,
        query: str,
        state: ConversationState
    ) -> dict:
        # Step 1: переформульовуємо запит з урахуванням історії
        standalone_query = self._rewrite_query(query, state.history)

        # Step 2: пошук за переформульованим запитом
        results = self.search.search(standalone_query, final_k=6)

        # Step 3: генерація відповіді з історією як контекстом
        answer = self._generate_answer(query, standalone_query, results, state)

        # Step 4: оновлюємо стан
        state.history.append((query, answer["text"]))
        if len(state.history) > 10:
            state.history = state.history[-10:]  # sliding window

        return answer

    def _rewrite_query(self, query: str, history: list) -> str:
        if not history:
            return query

        history_text = "\n".join([
            f"User: {h[0]}\nAssistant: {h[1][:200]}..."
            for h in history[-3:]  # останні 3 обміни
        ])

        result = self.llm.invoke(
            self.REWRITE_PROMPT.format(history=history_text, query=query)
        )
        return result.content.strip()

Управління контекстним вікном

При довгих сесіях історія не вміщається в context window. Рішення — ієрархічне стиснення:

class ContextManager:
    def __init__(self, llm, max_history: int = 10):
        self.llm = llm
        self.max_history = max_history

    def compress_history(self, history: list) -> str:
        """Стискаємо стару історію в коротке резюме сесії"""
        if len(history) <= self.max_history:
            return None

        old_turns = history[:-self.max_history]
        summary_prompt = f"""Стисни історію діалогу в коротке резюме (3–5 речень).
Збережи: ключові сутності, часові періоди, фільтри що згадувалися.

Історія:
{chr(10).join([f'U: {h[0]}' for h in old_turns])}

Резюме:"""
        return self.llm.invoke(summary_prompt).content

Практичний кейс

З нашої практики — юридична компанія, 120 юристів, база з 80 000 договорів та прецедентів. Типовий діалог:

Юрист: «Знайди договори оренди з порушенням строку повідомлення»
→ rewritten: «договори оренди де порушено строк повідомлення про зміну умов»

Юрист: «Тільки за вибраний рік»
→ rewritten: «договори оренди де порушено строк повідомлення про зміну умов, укладені у вибраному році»

Юрист: «А де орендар — юридична особа?»
→ rewritten: «договори оренди де порушено строк повідомлення, вибраний рік, орендар — юридична особа»

Після впровадження: середній час пошуку по базі прецедентів — з 18 хвилин до 2,5 хвилин. Юристи проводять 3–5 turns в середньому на сесію, 78% завдань вирішується без виходу з діалогу.

Персоналізація під роль користувача

ROLE_SYSTEM_PROMPTS = {
    "lawyer": "Ти — асистент юриста. Цитуй договори із зазначенням статей.",
    "hr": "Ти — HR-асистент. Відповідай в термінах HR-процесів, посилайся на регламенти.",
    "engineer": "Ти — технічний асистент. Включай технічні деталі, посилання на документацію.",
}

Як впливає персоналізація на релевантність результатів?

Персоналізація підвищує релевантність результатів на 35%. Ми налаштовуємо системний промпт під роль: lawyer, HR, engineer. Кожна роль отримує відповіді у своїй термінології, що скорочує час на інтерпретацію.

Поетапний план впровадження конверсаційного пошуку

1. Аналіз джерел та профілювання запитів — визначаємо типові патерни пошуку та структуру даних.
2. Проектування RAG-пайплайну — вибираємо модель ембеддінгів, векторну БД та стратегію chunking.
3. Реалізація ядра — пишемо query rewriting, контекстний менеджер та компонент ранжування.
4. Тестування на реальних запитах — проводимо A/B-тест на 1000+ запитах, вимірюємо NDCG та recall.
5. Деплой та інтеграція — розгортаємо REST API, вбудовуємо в існуючу CRM.

Що входить в розробку?

Строки: базовий conversational search — 3–4 тижні. З персоналізацією та компресією — 6–8 тижнів. Зв'яжіться з нами — оцінимо ваш проєкт безкоштовно.

Порівняння підходів: конверсаційний пошук vs BM25

Чому варто обрати конверсаційний пошук?

Кожен співробітник витрачає в середньому 2–3 години на день на пошук інформації. Наша система, за досвідом впроваджень, скорочує цей час на 60%. Гарантуємо: сертифіковані інженери (5+ років в AI), підтримка 24/7 після запуску. Звертайтеся — ми покажемо прототип на ваших даних за 2 дні.

Детальніше про ключову технологію — Retrieval-Augmented Generation.

Отримайте консультацію інженера та дізнайтеся, як conversational search змінить роботу з документами у вашій компанії. Зв'яжіться з нами для безкоштовної оцінки проєкту.

Практичний розбір LLM: fine-tuning, RAG, агенти, деплой

Модель GPT‑4 або Claude 3.5 Sonnet через публічне API — не рішення, а просто інструмент. Коли приходить вимога «зробити як ChatGPT, але на наших даних», за нею стоїть реальна інженерна задача: від налаштування промптів до навчання 70B‑моделі на власній інфраструктурі. LLM розробка під ключ — це складний стек, і ми займаємося цим понад 5 років. За цей час реалізовано понад 20 проєктів у галузі генеративного AI: від RAG‑систем для юридичних департаментів до кастомних агентів для техпідтримки. Де саме знаходиться ваша задача — залежить від даних, latency‑вимог, бюджету та того, наскільки критична конфіденційність.

Типова ситуація: клієнт уже спробував ChatGPT, але результати нестабільні — то відповідає точно, то галюцинує. Або потрібна інтеграція в корпоративний портал з дотриманням політик безпеки. Розберемо кожен шар стеку в деталях — від RAG до production‑деплою.

Чому RAG‑системи ламаються і як це виправити?

RAG (Retrieval‑Augmented Generation) виглядає просто: знайшли релевантні документи, поклали в контекст, модель відповіла. На практиці збоїть у кількох місцях.

Chunking без перекриття. Класична помилка: chunk_size=512, overlap=0. Якщо відповідь лежить на межі двох чанків, retrieval не знайде жодного з достатньою впевненістю. Рішення: overlap 15–25% від chunk_size, а краще sentence‑aware splitting через spaCy або NLTK, а не наївне розбиття за символами.

Поганий embedder. Текст‑embedding‑ada‑002 — хороший для загального випадку, але на юридичних або медичних текстах програє спеціалізованим моделям: E5‑large‑v2, BGE‑M3 або fine‑tuned sentence‑transformers на доменних даних. Різниця в Recall@5 може становити 15–25%.

Відсутність re‑ranking. Векторний пошук оптимізований за швидкістю, не за релевантністю. Cross‑encoder re‑ranker (ms‑marco‑MiniLM‑L‑6‑v2, bge‑reranker‑large) після первинного retrieval піднімає точність топ‑3 при прийнятній затримці (+50–150 ms). Це часто важливіше за покращення embedding‑моделі.

Гібридний пошук. Тільки dense вектори погано працюють на точних запитах: імена, артикули, коди. BM25 (sparse) добре знаходить точні збіги, але не розуміє семантику. Гібрид через RRF (Reciprocal Rank Fusion) — оптимальний компроміс. Qdrant, Weaviate та pgvector 0.7+ підтримують гібридний пошук нативно.

Коли варто fine‑tune, а не промпт‑інжиніринг?

Промпт‑інжиніринг вирішує ~70% завдань адаптації LLM під домен. Решта 30% вимагають донавчання. Три ознаки: модель ігнорує специфічний формат виведення навіть при детальному описі в промпті; задача вимагає глибокого знання спеціалізованої лексики (медицина, право); потрібно значно знизити витрати на токени, замінивши велику модель меншою спеціалізованою.

LoRA та QLoRA — стандарт для SFT. LoRA додає trainable low‑rank матриці до attention‑шарів. Типова конфігурація для Llama‑3 8B: r=64, lora_alpha=128, target_modules=["q_proj","v_proj","k_proj","o_proj"] — параметрів, що навчаються, ~0.8%, навчання на одній A100 40GB. QLoRA додає 4‑бітну квантизацію (NF4) і дозволяє fine‑tune 70B модель на двох A100 40GB, хоча швидкість падає вдвічі порівняно з bf16.

DPO замість RLHF. Direct Preference Optimization вимагає лише пари (chosen, rejected), а не скалярні reward‑сигнали. DPOTrainer з бібліотеки trl (Hugging Face) реалізує це кількома десятками рядків.

Типова помилка. Датасет з 500 прикладів, 5 епох, validation loss 0.8 — здається норм. Але на тесті модель деградувала на загальних інструкціях. Причина: catastrophic forgetting. Рішення — додати 10–20% загальних instruction‑following прикладів (Alpaca, FLAN) у навчальну вибірку, щоб не зруйнувати вихідні здібності.

Як обрати базову модель: 8B чи 70B?

Для більшості задач fine‑tuning 8B моделі достатньо. 70B потрібен, коли потрібне глибоке міркування або baseline 8B не досягає потрібної якості навіть після донавчання. Вартість інференсу Llama‑3 8B через vLLM на A100 значно нижча, ніж у GPT‑4, що робить його економічно вигідним.

Що дає PagedAttention в production?

vLLM — перший вибір для serving open‑source моделей. PagedAttention — ключове технічне рішення: KV‑cache керується як virtual memory в ОС, без фрагментації. Це дає throughput у 2–4 рази вище порівняно з наївним HuggingFace Transformers inference. Документація vLLM підтверджує: continuous batching та PagedAttention — стандарт для високонавантажених LLM‑сервісів.

Типові числа на A100 80GB для Llama‑3 8B (bf16): 400–600 req/s, P50 latency 200–400ms, P99 latency 600–900ms при concurrency 64. Для 70B на двох A100 з tensor parallelism: 80–120 req/s, P99 latency 1.5–2.5s. Квантизація AWQ або GPTQ знижує споживання пам'яті в 2 рази при втраті якості в межах 1–3%.

Мультиагентні системи

Агенти — LLM з доступом до інструментів: пошук, виконання коду, запити до API, робота з БД. Основні патерни:

• ReAct (Reason + Act): модель розмірковує → обирає інструмент → спостерігає результат → знову розмірковує. LangChain та LlamaIndex реалізують з коробки.
• Multi‑agent orchestration: кілька спеціалізованих агентів з координатором зверху. Приклад: coordinator → researcher (пошук + summarization) → coder (генерація та виконання коду) → critic (перевірка). Інструменти: AutoGen (Microsoft), CrewAI, кастомна реалізація на LangGraph.

В продакшені агентні системи недетерміновані. Обов'язкові guardrails, ліміти кроків, логування кожного кроку, human‑in‑the‑loop для критичних дій.

Як ми гарантуємо якість LLM рішення?

Ми використовуємо RAGAS для автоматичної оцінки відповідей: faithfulness, answer relevancy, context precision. Система трекінгу експериментів на базі MLflow фіксує всі метрики, датасети та конфіги. Це дозволяє порівнювати різні гіпотези та доводити покращення з цифрами. Гарантію стабільної роботи забезпечує continuous integration з тестами на специфічних сценаріях (prompt injection, edge‑cases).

Як почати LLM розробку: наступні кроки

Ми передаємо:

• Технічну документацію (model card, конфіги, інструкції з розгортання)
• Доступ до інфраструктури (репозиторій з кодом, навчені ваги)
• 1 місяць підтримки після деплою (консультації, виправлення багів)
• Навчання команди замовника (2–3 заняття з експлуатації системи)

Терміни: базовий RAG‑прототип — 1–2 тижні. Fine‑tuning з даними замовника — 3–6 тижнів (з урахуванням підготовки даних). Production‑система з моніторингом та перенавчанням — 2–4 місяці.

Вартість розраховується індивідуально і залежить від обсягу даних, складності моделі та вимог до інфраструктури. Хочете оцінити свій проєкт? Зв'яжіться з нами — ми підготуємо попереднє резюме за 1–2 робочі дні. Або замовте консультацію фахівця з вибору підходу: RAG, fine‑tuning або гібрид — розповімо, що підійде саме вам.