Гібридний AI-асистент для корпоративних даних: збереження експертизи

Іде ключовий співробітник — іде експертиза

База знань залишається, але знайти в ній відповіді — проблема. Стандартний LLM не знає вашу термінологію та процеси. AI-агент, навчений на даних цього співробітника, може відповідати так, як відповів би він сам. Ми розробляємо таких агентів під ключ: від збору даних до production. Головна мета — збереження експертизи співробітника, який йде з компанії.

Чому стандартний LLM не справляється?

Загальна модель дає узагальнені відповіді з інтернету. Вона не знає, що у вашій компанії "затвердження договору" проходить через три рівні погодження. Не знає, що в Confluence є шаблон звіту, а в Jira — історія аналогічних завдань. Точність відповідей на корпоративні процеси без донавчання — близько 67%. Агент, навчений на ваших даних, піднімає її до 91%, тобто в 1.36 рази точніше.

Проблеми, які ми вирішуємо

• Втрата експертизи при звільненні співробітника. Його унікальні знання з процесів, рішень і контактів залишаються в головах. AI-агент фіксує їх у моделі та RAG-індексі.
• Неструктурованість даних. 80% корпоративних знань — у Confluence, Jira, email. Ми збираємо, очищаємо та індексуємо їх у векторну базу (Qdrant, pgvector).
• Довгий пошук відповідей. Замість 15 хвилин на пошук у Confluence — один запит агенту. Зниження тікетів у техпідтримку на 34%.

Порівняння підходів навчання AI-агента

Гібридний підхід — єдиний, що забезпечує і точність стилю, і актуальність. Саме його ми використовуємо у всіх production-проєктах. Докладніше про RAG можна прочитати в Wikipedia. Наприклад, fine-tuning дає в 2.26 рази кращу точність термінології, ніж RAG, а гібридний підхід перевершує обидва методи за актуальністю.

Як ми збираємо та готуємо дані?

Джерела даних: Confluence (сторінки), Jira (вирішені тікети), email-листування (анонімізовані), корпоративні файли (PDF, DOCX).

Процес підготовки:

1. Збір даних через API (Confluence REST, Jira API, IMAP для пошти).
2. Очищення: html-to-text, дедуплікація, фільтр якості (видаляємо відповіді коротші 50 токенів).
3. Генерація синтетичних Q&A з документів — використовуємо GPT-4o-mini для створення до 10 пар на документ.
4. Розмітка формату: OpenAI messages format (system/user/assistant).

Процес навчання на корпоративних даних включає збір даних з Confluence, Jira та email, а потім генерацію синтетичних Q&A пар за допомогою GPT-4o-mini. Для оркестрації агента використовується LangChain, а векторну базу Qdrant. Ми дотримуємося MLOps практик для відстеження експериментів.

Приклад коду збірника даних:

from pathlib import Path
from typing import Generator
import json

class CorporateDataCollector:
    """Збір даних з корпоративних джерел"""

    async def collect_from_confluence(self, space_keys: list[str]) -> list[dict]:
        """Сторінки Confluence"""
        docs = []
        for space in space_keys:
            pages = await confluence_client.get_all_pages(space)
            for page in pages:
                content = await confluence_client.get_page_content(page["id"])
                docs.append({
                    "source": "confluence",
                    "id": page["id"],
                    "title": page["title"],
                    "content": html_to_text(content),
                    "updated_at": page["version"]["when"],
                    "labels": page.get("labels", []),
                    "space": space,
                })
        return docs

    async def collect_from_email_threads(
        self,
        email_accounts: list[str],
        filter_subjects: list[str] = None,
        anonymize_pii: bool = True,
    ) -> list[dict]:
        """Email-листування як навчальні дані для діалогів"""
        threads = []
        for account in email_accounts:
            emails = await gmail_client.get_threads(account, filter_subjects)
            for thread in emails:
                if len(thread["messages"]) >= 2:
                    # Перетворюємо листування у формат діалогу
                    dialog = self.format_as_dialog(thread["messages"])
                    if anonymize_pii:
                        dialog = await self.anonymize_pii(dialog)
                    threads.append(dialog)
        return threads

    async def collect_from_tickets(
        self,
        jira_project: str,
        status: str = "Done",
        limit: int = 5000,
    ) -> list[dict]:
        """Вирішені тікети як Q&A пари"""
        tickets = await jira_client.get_issues(
            jql=f"project={jira_project} AND status={status}",
            fields=["summary", "description", "comments", "resolution"],
            limit=limit,
        )

        qa_pairs = []
        for ticket in tickets:
            if ticket.get("comments"):
                qa_pairs.append({
                    "question": f"{ticket['summary']}\n{ticket.get('description', '')[:500]}",
                    "answer": self.extract_resolution(ticket),
                    "source": "jira",
                    "ticket_id": ticket["id"],
                })

        return qa_pairs

class FinetuningDatasetBuilder:

    async def build_instruction_dataset(
        self,
        raw_docs: list[dict],
        qa_pairs: list[dict],
        target_format: str = "openai",  # "openai", "alpaca", "sharegpt"
    ) -> list[dict]:

        dataset = []

        # З документів — генеруємо Q&A через LLM
        for doc in raw_docs:
            qa_from_doc = await self.generate_qa_from_document(doc["content"])
            for qa in qa_from_doc:
                if target_format == "openai":
                    dataset.append({
                        "messages": [
                            {"role": "system", "content": "Ти — корпоративний асистент компанії. Відповідай на запитання співробітників."},
                            {"role": "user", "content": qa["question"]},
                            {"role": "assistant", "content": qa["answer"]},
                        ]
                    })

        # З тікетів — готові пари
        for qa in qa_pairs:
            if target_format == "openai":
                dataset.append({
                    "messages": [
                        {"role": "system", "content": "Ти — асистент технічної підтримки."},
                        {"role": "user", "content": qa["question"]},
                        {"role": "assistant", "content": qa["answer"]},
                    ]
                })

        # Дедуплікація та фільтрація
        dataset = self.deduplicate(dataset)
        dataset = self.filter_quality(dataset, min_answer_length=50)

        return dataset

    async def generate_qa_from_document(self, document_text: str) -> list[dict]:
        """Генерує Q&A пари з документа"""
        response = await openai_client.chat.completions.create(
            model="gpt-4o-mini",
            messages=[{
                "role": "user",
                "content": f"""Створи 5-10 запитань і відповідей із наступного документа.
Запитання мають бути такими, як їх задають реальні співробітники.
Відповіді — повними та точними.

Документ:
{document_text[:3000]}

Поверни JSON: [{"question": "...", "answer": "..."}]"""
            }],
        )
        return json.loads(response.choices[0].message.content)

    def filter_quality(self, dataset: list[dict], min_answer_length: int) -> list[dict]:
        """Фільтрує дані низької якості"""
        filtered = []
        for item in dataset:
            messages = item.get("messages", [])
            assistant_msg = next((m for m in messages if m["role"] == "assistant"), None)
            if assistant_msg and len(assistant_msg["content"]) >= min_answer_length:
                filtered.append(item)
        return filtered

Як працює гібридна архітектура: fine-tune + RAG

Fine-tune модель знає стиль і термінологію компанії. RAG додає актуальні документи. Об'єднуємо їх в одному агенті:

from sentence_transformers import SentenceTransformer
from openai import OpenAI
from qdrant_client import QdrantClient

class HybridCorporateAgent:
    """Об'єднує файнтюн-модель зі стилем компанії та RAG з актуальними знаннями"""

    def __init__(self):
        # Файнтюн-модель знає стиль і термінологію компанії
        self.finetuned_client = OpenAI(base_url="http://vllm-server:8000/v1")
        self.finetuned_model = "company-assistant-ft-v2"

        # RAG для актуальних документів
        self.embed_model = SentenceTransformer("BAAI/bge-m3")
        self.vector_db = QdrantClient(host="qdrant-server")

    async def answer(self, question: str, user_context: dict = None) -> dict:
        # Крок 1: Пошук релевантних документів
        query_embedding = self.embed_model.encode(question)
        relevant_docs = self.vector_db.search(
            collection_name="corporate_docs",
            query_vector=query_embedding,
            limit=5,
            score_threshold=0.6,
            query_filter=self.build_access_filter(user_context),  # Права доступу
        )

        # Крок 2: Формування контексту
        context = "\n\n".join([
            f"[{doc.payload['title']}]: {doc.payload['content']}"
            for doc in relevant_docs
        ])

        # Крок 3: Відповідь файнтюн-моделлю з RAG-контекстом
        response = self.finetuned_client.chat.completions.create(
            model=self.finetuned_model,
            messages=[{
                "role": "system",
                "content": f"Ти — корпоративний асистент. Використовуй документи як джерело істини.\n\nДокументи:\n{context}"
            }, {
                "role": "user",
                "content": question,
            }],
            temperature=0.1,
        )

        return {
            "answer": response.choices[0].message.content,
            "sources": [{"title": d.payload["title"], "score": d.score} for d in relevant_docs],
        }

    def build_access_filter(self, user_context: dict):
        """Фільтрація за правами доступу — співробітник бачить тільки свої документи"""
        if not user_context:
            return None

        department = user_context.get("department", "all")
        clearance = user_context.get("clearance", "public")

        return {
            "must": [
                {"key": "access_level", "match": {"any": [clearance, "public"]}},
                {"key": "departments", "match": {"any": [department, "all"]}},
            ]
        }

Для зменшення витрат на інференс ми застосовуємо квантування (bitsandbytes) та LoRA (Low-Rank Adaptation) для параметро-ефективного донавчання. Це дозволяє знизити latency на 40% та використовувати менші GPU.

Кейс з нашої практики: IT-компанія, 300 співробітників

Наш клієнт — IT-компанія з 300 співробітників — звільнявся старший розробник, який вів ключові процеси. За 5 років він накопичив 8 000 сторінок у Confluence, брав участь у вирішенні 12 000 тікетів Jira. Ми зібрали та очистили дані за 3 тижні, згенерували 45 000 синтетичних Q&A пар, донавчили GPT-4o-mini на 60 000 прикладах (3 епохи), завантажили всі документи в Qdrant. Результат: точність відповідей на корпоративні процеси 91% проти 67% у базового GPT-4o (у 1.36 рази точніше), правильна термінологія 97% проти 43%, зниження тікетів у техпідтримку на 34%. В результаті клієнт економить понад $50,000 на рік завдяки зниженню навантаження на техпідтримку.

Що входить у роботу

Скільки часу займає розробка?

Від 8 до 13 тижнів залежно від обсягу та якості даних. Більшу частину часу займає збір і очищення — їх не прискорити без втрати якості. Вартість розраховується індивідуально, виходячи з кількості джерел та необхідної точності. Типовий бюджет проєкту — від $15,000 до $30,000.

Типові помилки при навчанні AI-агента

• Ігнорування прав доступу. Без фільтрації співробітник може побачити документи іншого відділу. Наша архітектура включає build_access_filter, який перевіряє департамент і рівень допуску.
• Використання тільки RAG. Без fine-tuning модель не засвоює корпоративний стиль — відповіді звучать як з інтернету, а не від колеги.
• Слабкий quality filtering. Якщо в датасет потрапляють погані відповіді (коротші 50 токенів або без фактів), якість падає. Ми фільтруємо за мінімальною довжиною та семантичною близькістю.
• Відсутність тестування на реальних запитаннях. Синтетичні тести не показують прогалини. Перевіряємо на 500+ питаннях від майбутніх користувачів.

Чому варто замовити розробку у нас?

5 років досвіду в NLP та MLOps, 30+ впроваджених AI-агентів. Гарантуємо, що агент відповідатиме з точністю не нижче 85% на заявлені процеси. Використовуємо тільки перевірені інструменти: Hugging Face, Qdrant, vLLM, ONNX Runtime. Після здачі — підтримка та донавчання в міру накопичення нових даних.

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

Практичний розбір 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 або гібрид — розповімо, що підійде саме вам.