Все статьи
обновлено 10 мин

AI-помощник по корпоративной базе знаний: технический разбор архитектуры

Как технически устроен корпоративный AI-помощник по документам: от парсинга до ответа со ссылками. Реальный stack AGmind и компромиссы при выборе компонентов.

архитектураragknowledge-baseself-hosted-aiagmindvector-search

Корпоративный AI-помощник по базе знаний — это не одна модель, а архитектура из 8-10 компонентов, каждый из которых отвечает за свою задачу. Когда говорят “AI-чат по документам”, обычно имеют в виду RAG-систему (Retrieval-Augmented Generation), но за этим стоит конкретный стек технических решений с компромиссами на каждом шаге.

Этот текст — про реальную архитектуру, которую мы используем в AGmind. Без маркетинговых упрощений, с разбором почему выбраны именно эти компоненты и где можно было бы пойти иначе.

Высокоуровневая архитектура

┌─────────────────────────────────────────────────────────────┐
│ Пользовательский слой (Dify / Telegram-бот / API)            │
└──────────────────────┬──────────────────────────────────────┘
                       │
┌──────────────────────▼──────────────────────────────────────┐
│ Оркестратор (Dify Workflow / агент)                          │
│  - роутинг запроса                                           │
│  - composition промпта                                       │
│  - постобработка ответа                                      │
└──────────────────────┬──────────────────────────────────────┘
                       │
        ┌──────────────┴──────────────────┐
        │                                 │
┌───────▼────────┐               ┌────────▼─────────┐
│ Retrieval      │               │ LLM              │
│ - Эмбеддер     │               │ - vLLM сервис    │
│ - Векторная БД │               │ - Llama 70B /    │
│ - Реранкер     │               │   Qwen 32B / etc │
│ - BM25 search  │               └──────────────────┘
└───────┬────────┘
        │
┌───────▼────────┐
│ Document Layer │
│ - Парсер PDF   │
│ - OCR (если   │
│   нужно)       │
│ - Chunker      │
│ - Vision LLM   │
│   для картинок │
└────────────────┘

Каждый блок — отдельный сервис в контейнере. Все стыкуются через стандартные API (HTTP, gRPC).

Слой 1: парсинг документов

Задача: превратить PDF/DOCX/PPTX/XLSX в структурированный markdown с сохранением иерархии (заголовки, таблицы, списки) и описаниями картинок.

Используем:

  • Docling (IBM, GPU-accelerated) — основной парсер для текстовых PDF. Быстрый (1-3 секунды на страницу), хорошо держит таблицы, выдаёт чистый markdown
  • RAGFlow (специализированный) — для сложных документов: сканированные PDF, документы с картинками, отчёты с многоколоночной вёрсткой
  • Unstructured.io — fallback для DOCX/PPTX/XLSX/HTML

Вышли альтернативы которые рассмотрели и отвергли:

  • PyPDF2 / pdfplumber — слишком слабый, теряет таблицы и форматирование
  • GROBID — академическая ориентация, плохо на бизнес-документах
  • Azure Document Intelligence / Yandex AI — облачные, не подходят для self-hosted

OCR (для отсканированных PDF):

  • Cascade-OCR через RAGFlow — поддерживает Latin/Cyrillic/Chinese
  • EasyOCR — fallback для ультра-плохих сканов

Качество OCR определяет всё дальше. Если в OCR попало «г.0рловка» вместо «г. Горловка», AI это запомнит как факт.

Слой 2: vision LLM для картинок и схем

Задача: превратить картинки и диаграммы внутри документов в текстовое описание, чтобы они попали в RAG-индекс.

Используем:

  • Gemma 4 vision-instruct для русских документов
  • Qwen-VL для смешанных языковых случаев

Pipeline:

  1. Парсер выделяет картинки из документа
  2. Каждая картинка отправляется в vision LLM с промптом «опиши что на изображении подробно»
  3. Описание встраивается в markdown на месте картинки
  4. Дальше как обычный текст — чанкируется, эмбеддится, индексируется

Когда нужно: документация со схемами, презентации, инженерные чертежи, инфографика. Без vision-LLM эти документы становятся бесполезными для AI.

Слой 3: чанкинг

Задача: нарезать документы на куски такого размера, чтобы каждый помещался в LLM-контекст вместе с запросом и ответом, при этом не разрывая логические единицы.

Используем три типа чанкинга:

  1. Recursive character chunking (стандартный) — режет по параграфам с overlap’ом 200 токенов. Подходит для прозы, регламентов, методичек.
  2. Title hierarchy chunking (5-уровневая иерархия) — для документов с чёткой структурой (главы → разделы → пункты). Сохраняет parent context в каждом чанке.
  3. Token chunker для атомарных таблиц — таблицы не режутся пополам, идут целиком как один чанк (если помещаются) или с обязательным сохранением header’а в каждой части.

Параметры:

  • Размер чанка: 500-1500 токенов (sweet spot для bge-m3)
  • Overlap: 100-200 токенов
  • Минимальный чанк: 100 токенов (мелкие куски склеиваются с соседними)

Слой 4: эмбеддинг

Задача: превратить каждый чанк в вектор фиксированной размерности (1024) для семантического поиска.

Используем:

  • deepvk/USER-bge-m3 — для русских корпоративных документов (default)
  • BAAI/bge-m3 — для мультиязычных документов

Подробное сравнение моделей — в статье про эмбеддеры.

Inference:

  • Через vLLM (single GPU, batch processing 64-128 параллельных)
  • Скорость: ~2000 чанков в минуту на DGX Spark
  • Память: 2.3 GB VRAM

Слой 5: векторная база

Задача: хранить эмбеддинги и быстро искать топ-N похожих по запросу.

Используем Weaviate по причинам:

  • Hybrid search (vector + BM25) встроен из коробки
  • Поддерживает 100M+ векторов на одной ноде
  • Хорошие операционные характеристики (горячая перезагрузка, snapshots, replication)
  • Open-source с активной комьюнити

Альтернативы которые рассматривали:

  • Qdrant — быстрее в чистом vector search, но без встроенного BM25 hybrid. Подходит для real-time use-case’ов
  • Milvus — для очень больших масштабов (1B+ векторов). Overkill для большинства корпоративных кейсов
  • pgvector (PostgreSQL extension) — для случаев когда уже есть Postgres и не хочется отдельного сервиса. Производительность ниже специализированных
  • Chroma — для прототипов и небольших баз (<1M векторов)

Слой 6: реранкер

Задача: из топ-20 кандидатов после векторного поиска выбрать топ-3-5 самых точных для отправки в LLM.

Используем BAAI/bge-reranker-v2-m3:

  • Специальная архитектура (cross-encoder), сравнивает пары «запрос-чанк» точнее чем bi-encoder эмбеддер
  • Работает на тот же mulitlingual датасет, поддерживает русский
  • Скорость: ~50 пар в секунду на одном GPU

Без реранкера качество финального ответа падает на 10-20% — эмбеддеры приближённы, реранкер делает финальную сортировку.

Задача: объединить семантический (vector) поиск с классическим текстовым (BM25) для лучшего recall на запросах с конкретными именами/числами/кодами.

В Weaviate:

search(
  query="штрафы за просрочку поставки в договоре №432",
  alpha=0.7,  # 70% веса векторам, 30% BM25
  limit=20
)

Vector часть находит семантически похожие чанки даже без точных слов. BM25 часть гарантирует что чанки с конкретным «договор №432» попадут в результат.

Hybrid search даёт +5-10% recall на сложных запросах.

Слой 8: LLM-сервис

Задача: генерировать финальный ответ на основе предоставленного контекста (топ-5 чанков от реранкера).

Используем vLLM:

  • Модель: Llama 3.3 70B (или Qwen 3, или Gemma 4 26B в зависимости от железа)
  • Контекст: до 128K токенов (помещаются 5-10 чанков плюс запрос + history)
  • Концепция: PagedAttention для эффективной памяти, continuous batching для пропускной способности
  • Скорость: 23-50 токенов/сек на одиночный запрос, до 400 toks/sec при concurrency

Промпт:

Ты корпоративный ассистент. Отвечай только на основе предоставленных документов.
Если ответа в документах нет — говори "не знаю".
В каждом утверждении указывай источник в формате [doc_name, страница X].

Документы:
[Чанк 1: ...]
[Чанк 2: ...]
...

Вопрос пользователя: ...

Ответ:

Слой 9: оркестратор

Задача: управлять flow обработки запроса — что в каком порядке делать, какие модели использовать, как форматировать ответ.

Используем Dify:

  • Drag-n-drop workflow builder
  • Готовые блоки для retrieval, генерации, postprocessing
  • Поддержка multi-step рассуждений и агентов
  • Web-интерфейс для пользователей и API для интеграций

Альтернативы:

  • LangChain / LlamaIndex — программное управление, более гибко но требует кода
  • n8n — workflow automation общего назначения, можно использовать но менее специализирован под AI

Слой 10: пользовательский слой

Задача: дать пользователям удобный интерфейс.

Каналы доступа:

  1. Dify web-чат — основной для desktop-пользователей
  2. Telegram-бот — для мобильного доступа и быстрых вопросов
  3. API — для интеграции в существующие системы (CRM, корп. портал)
  4. Slack/Mattermost integration — если используется в команде

Все каналы используют тот же бэкенд, разница только в интерфейсе.

Производительность на реальной нагрузке

Замеры на DGX Spark с базой из 50K документов (200K чанков):

  • Поиск (retrieval + rerank): 280-450 мс
  • Генерация ответа (top-5 контекст, 500 токенов output): 12-18 секунд
  • Полный round-trip: 12-19 секунд от запроса до окончательного ответа
  • Concurrency: 30-45 параллельных запросов без деградации

Для большинства корпоративных кейсов это нормально. Если нужно быстрее (real-time голос) — больше железа или более лёгкие модели.

Безопасность и compliance

Изоляция: весь стек работает в изолированной сети, без выхода в интернет (кроме опционального обновления моделей).

Аудит-логи: каждый запрос и ответ записываются с временной меткой, user ID, источниками контекста. Нужно для compliance в финансах/медицине/госзаказах.

Доступы: интеграция с корп. SSO (Active Directory / Keycloak), RBAC на уровне коллекций документов (юристы видят свою базу, HR — свою).

Что дальше — направления развития

  • Multi-modal: добавление обработки голоса (транскрипция звонков, поиск по аудио-записям совещаний)
  • Tool-using agents: AI способный делать действия (отправить email, создать задачу в CRM, вызвать API)
  • Long-term memory: персональная память по каждому пользователю, накапливаемая между сессиями
  • Continuous fine-tuning: автоматическое улучшение модели на основе пользовательских отметок «хорошо/плохо»

Все эти направления — следующая волна для корпоративных AI после того как базовый RAG-помощник стабильно работает.

Итог

Корпоративный AI-помощник — это не одна модель и не «плагин». Это полноценная микросервисная архитектура из 10 слоёв, каждый из которых требует осмысленного выбора компонентов. AGmind — наш конкретный взвешенный выбор для русского B2B на 2026 год.

Если хочется обсудить архитектуру под вашу специфику — пилот за 2-3 недели включает архитектурный аудит и proof-of-concept. От 100 000 ₽.

Для понимания того, как техническая архитектура соотносится с executive-уровнем корпоративного ИИ-помощника — читайте executive-уровень корпоративного ИИ-помощника.

Технические детали реального deploy — в статье про DGX Spark setup на Habr. Про эмбеддеры — отдельно. Про RAG в общем — explainer.