Разработка системы обучения AI-агента на данных предыдущего сотрудника

Уходит ключевой сотрудник — уходит экспертиза

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

Почему стандартный LLM не справляется?

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

Какие проблемы решаем?

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

Какой подход обучения AI-агента выбрать?

Гибридный подход — единственный, обеспечивающий и точность стиля, и актуальность. Именно его мы используем во всех production-проектах. Подробнее о RAG можно прочитать в Wikipedia.

Как мы собираем и подготавливаем данные?

Источники данных: 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).

Пример кода сборщика данных:

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"]}},
            ]
        }

Кейс из нашей практики: 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, правильная терминология 97% против 43%, снижение тикетов в техподдержку на 34%.

Что входит в работу

Сколько времени занимает разработка?

От 8 до 13 недель в зависимости от объёма и качества данных. Большую часть времени занимает сбор и очистка — их не ускорить без потери качества. Стоимость рассчитывается индивидуально, исходя из количества источников и требуемой точности.

Типичные ошибки при обучении 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 — около $0.001/1K токенов, что в 15 раз дешевле 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 для критических действий.

Как мы работаем: этапы, сроки, результат

Что входит в работу

Мы передаём:

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

Сроки: базовый RAG‑прототип — 1–2 недели. Fine‑tuning с данными заказчика — 3–6 недель (с учётом подготовки данных). Production‑система с мониторингом и переобучением — 2–4 месяца. Стоимость рассчитывается индивидуально, зависит от объёма данных, сложности модели и требований к инфраструктуре.

Хотите оценить свой проект? Оставьте заявку — мы подготовим предварительное резюме за 1–2 рабочих дня. Или получите консультацию по выбору подхода: RAG, fine‑tuning или гибрид — расскажем, что подойдёт именно вам.