AI-система керування знаннями: як впровадити в компанії

У компанії зі 100 інженерів 40% робочого часу йде на пошук уже вирішених проблем. Документація в Confluence не оновлюється, нові співробітники витрачають тижні на введення в курс справи. Втрати часу еквівалентні зарплаті цілого розробника — компанія втрачає до 20% бюджету на онбординг через відсутність актуальної бази знань. AI-система управління знаннями вирішує цю проблему автоматичним вилученням знань з Slack, Jira та Git — без навантаження на команду. На відміну від ручного документування, яке ніколи не встигає за потоком, RAG-пайплайн на LangChain та GPT-4o переробляє тисячі повідомлень на день, перетворюючи їх на структуровану базу, доступну через єдиний пошук.

Ми реалізували такий pipeline на LangChain + Qdrant + GPT-4o. Більше 5 років досвіду в AI/ML та 15+ проєктів з впровадження RAG дозволяють нам гарантувати стабільну обробку 1000+ повідомлень на день без втрати точності. У типовій команді з 50 розробників щомісяця генерується близько 3000 повідомлень у Slack та 200 завершених тікетів у Jira — ручне документування просто не встигає. Система захоплює цей потік і перетворює його на структуровану базу, доступну через єдиний пошук. Скорочення часу пошуку на 80% — не поодинокий результат, а середнє значення по всіх наших проєктах. Дослідження показують, що автоматизація Knowledge Management знижує операційні витрати на 30%.

Автоматичне вилучення знань із робочих процесів

Замість того щоб просити людей документувати, система сама аналізує існуючі потоки даних і структурує знання в єдину базу.

from langchain_openai import ChatOpenAI
from langchain_community.vectorstores import Qdrant
from sentence_transformers import SentenceTransformer
from datetime import datetime
import json

class KnowledgeExtractionPipeline:
    """Вилучає знання з неструктурованих джерел"""

    EXTRACTION_PROMPT = """Проаналізуй текст та вилучи структуроване знання.

Текст (джерело: {source}):
{text}

Визнач:
1. Тип знання: вирішення_проблеми | best_practice | процес | визначення | кейс
2. Заголовок (до 10 слів)
3. Суть знання (2–4 речення, лише факти)
4. Умови застосування (коли це знання актуальне)
5. Пов'язані теми/теги
6. Впевненість у якості (0–1): наскільки текст містить реальне знання

Поверни JSON. Якщо знання немає (small talk, статус-апдейт) — поверни null."""

    def __init__(self, llm: ChatOpenAI, vector_store: Qdrant):
        self.llm = llm
        self.vector_store = vector_store
        self.embedder = SentenceTransformer("intfloat/multilingual-e5-large")

    async def process_slack_thread(self, thread: dict) -> list[dict]:
        """Вилучає знання з Slack-треду"""
        thread_text = "\n".join([
            f"{msg['user']}: {msg['text']}"
            for msg in thread["messages"]
        ])

        result = await self.llm.ainvoke(
            self.EXTRACTION_PROMPT.format(
                source=f"Slack #{thread['channel']}",
                text=thread_text[:3000]
            )
        )

        try:
            knowledge = json.loads(result.content)
            if knowledge and knowledge.get("confidence", 0) >= 0.7:
                return [self._store_knowledge(knowledge, thread)]
        except Exception:
            pass
        return []

    async def process_jira_ticket(self, ticket: dict) -> list[dict]:
        """Вилучає знання з вирішеного тікета"""
        if ticket["status"] != "Done":
            return []

        text = f"""Проблема: {ticket['title']}
Опис: {ticket.get('description', '')}
Коментарі: {' '.join([c['body'] for c in ticket.get('comments', [])])}
Рішення: {ticket.get('resolution', '')}"""

        return await self._extract_and_store(text, f"Jira {ticket['key']}")

Чому граф знань ефективніший за пошук за тегами?

Розрізнені статті — слабка база знань. Граф знань пов'язує концепції і дозволяє відповідати на питання типу «що ще пов'язано з цією проблемою?»

import networkx as nx
from sklearn.metrics.pairwise import cosine_similarity
import numpy as np

class KnowledgeGraph:
    def __init__(self):
        self.graph = nx.DiGraph()
        self.node_embeddings = {}

    def add_knowledge_node(self, knowledge_id: str, knowledge: dict, embedding: np.ndarray):
        self.graph.add_node(knowledge_id, **knowledge)
        self.node_embeddings[knowledge_id] = embedding

        # Автоматично будуємо зв'язки з семантично близькими вузлами
        self._auto_link(knowledge_id, embedding, threshold=0.75)

    def _auto_link(self, new_id: str, new_emb: np.ndarray, threshold: float):
        if len(self.node_embeddings) < 2:
            return

        existing_ids = [k for k in self.node_embeddings if k != new_id]
        existing_embs = np.array([self.node_embeddings[k] for k in existing_ids])

        similarities = cosine_similarity([new_emb], existing_embs)[0]

        for node_id, sim in zip(existing_ids, similarities):
            if sim >= threshold:
                self.graph.add_edge(new_id, node_id, weight=float(sim), type="related")

    def get_related(self, knowledge_id: str, depth: int = 2) -> list[str]:
        """Повертає пов'язані вузли до зазначеної глибини"""
        if knowledge_id not in self.graph:
            return []
        return list(nx.ego_graph(self.graph, knowledge_id, radius=depth).nodes)

Як запобігти застаріванню знань?

Знання старіють. Стаття про налаштування VPN на старій версії ПЗ — гірша, ніж її відсутність: вона вводить в оману.

class KnowledgeFreshnessChecker:
    STALENESS_CHECK_PROMPT = """Оціни актуальність наступної статті.

Стаття (створена: {created_date}):
{content}

Останні пов'язані зміни в репозиторії:
{recent_commits}

Визнач:
1. Статус: актуально | застаріло | потребує_перевірки
2. Причина (якщо застаріло/потребує перевірки)
3. Рекомендована дія

Поверни JSON."""

    async def check_article(self, article: dict, related_commits: list) -> dict:
        result = await self.llm.ainvoke(
            self.STALENESS_CHECK_PROMPT.format(
                created_date=article["created_at"],
                content=article["content"][:1500],
                recent_commits="\n".join([
                    f"- {c['date']}: {c['message']}"
                    for c in related_commits[:10]
                ])
            )
        )
        return json.loads(result.content)

Кейс: розробницька компанія, 80 інженерів. До впровадження: 340 статей у Confluence, 60% не оновлювалися понад рік, команда не довіряла документації. Після 6 місяців роботи AI-системи: вилучено 1200+ одиниць знань із Slack-тредів та Jira-тікетів, 89 статей позначено як застарілі та відправлено на рев'ю власникам. Індекс довіри до документації (опитування команди): 2.1/5 → 3.9/5.

Як AI-система інтегрується з існуючою інфраструктурою?

Інтеграція виконується через REST API та вебхуки. Система підтримує OAuth 2.0 для Slack, Jira, GitLab/GitHub — не потребує зберігання паролів. Розгортається у вашому Kubernetes-кластері або у приватній хмарі (підтримуються AWS EKS, GKE, Azure AKS). Для невеликих команд доступна on-prem версія на Docker Compose. Адаптер для нового джерела (наприклад, внутрішній чат) пишеться за 1–2 тижні та підключається без зупинки решти pipeline. Отримайте консультацію для оцінки сумісності вашої інфраструктури.

Що робити, якщо дані містять конфіденційну інформацію?

AI-система вилучає знання, але не зберігає вихідні повідомлення — лише структуровані JSON-блоки. Можна налаштувати фільтр на рівні входу: виключати канали з грифом "секретно" або маскувати імена користувачів. LLM обробляє текст у вашому контурі — дані не йдуть до зовнішніх провайдерів (якщо використовується self-hosted модель, наприклад Mistral або LLaMA). Аудит безпеки проводимо на етапі пілоту. Зв'яжіться з нами, щоб обговорити вимоги до безпеки.

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

• Архітектурний документ із описом пайплайну та вибраного стеку
• Реалізація pipeline вилучення з Slack + Jira (інші джерела підключаються за 1–2 тижні кожне)
• Розгортання векторної бази (Qdrant) та графа знань
• Налаштування автоматичної перевірки актуальності знань
• Інтеграція з існуючими інструментами (Slack, Jira, Git, тощо)
• Навчання команди (1 воркшоп на 2 години)
• Підтримка на 2 тижні після запуску

Порівняння: база знань без AI vs з AI

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

Ми гарантуємо, що pipeline буде обробляти не менше 1000 повідомлень на день без втрати точності. Оцінюємо проєкт за 2 дні — обговоріть вашу інфраструктуру з нашими інженерами. Під ключ за 8–12 тижнів.

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