Корпоративная тайна в безопасности: собираем локальный AI-стек для анализа документов без облаков

Зачем вам этот ад из трёх инструментов?

Потому что корпоративные юристы не хотят, чтобы их договоры летали по OpenAI API. Финансовые аналитики не желают загружать отчёты в Google NotebookLM. И все вместе ненавидят, когда конфиденциальные документы утекают через сторонние сервисы.

Облачные AI-инструменты - это удобно, пока не касается реальных данных. Как только вы начинаете загружать настоящие контракты, финансовые отчёты или медицинские записи, возникает вопрос: "А кто ещё это видит?" Ответ обычно неприятный.

Архитектура, которая не сломается после первого документа

Типичная ошибка - ставить всё на одной машине и удивляться, почему 40-страничный PDF убивает систему. Наша архитектура разделяет роли:

• LM Studio - только инференс моделей, запускаем на машине с GPU
• Aleph RLM - обработка документов и RAG, работает на CPU-сервере
• LibreChat - фронтенд и управление диалогами, отдельный веб-сервер

Почему так? Потому что LM Studio жрёт видеопамять как голодный зверь. Aleph RLM обрабатывает документы - это CPU-интенсивная задача. LibreChat просто показывает интерфейс. Разделяем и властвуем.

Шаг 1: LM Studio - ставим мозги системы

Не скачивайте первую попавшуюся модель. Для корпоративного анализа документов на 05.02.2026 нужны специфичные вещи:

1. Загружаем LM Studio 0.3.9 с официального сайта (да, там есть Windows, macOS и Linux версии)
2. В настройках включаем API-сервер: порт 1234, CORS разрешаем для вашего домена
3. Выбираем модель. Не Mistral, не Llama. Для документов берём Qwen2.5-Coder-32B-Instruct-GGUF - она понимает таблицы, код в документах и длинные контексты до 128к токенов

// Конфигурация LM Studio API-сервера
{
  "server": {
    "host": "0.0.0.0",
    "port": 1234,
    "cors": ["http://ваш-домен:3000"],
    "timeout": 300  // 5 минут для больших документов
  },
  "model": {
    "path": "./models/Qwen2.5-Coder-32B-Instruct-Q4_K_M.gguf",
    "context_length": 131072,
    "gpu_layers": 40  // для 24GB VRAM
  }
}

Шаг 2: Aleph RLM - интеллектуальная обработка документов

Aleph RLM 2.8 - это не просто RAG. Это рекурсивная обработка: документ разбивается на смысловые блоки, каждый блок анализируется, затем строится общее понимание. Как работает:

# Устанавливаем Aleph RLM
pip install aleph-rlm==2.8

# Создаём базу для документов
aleph init --path ./corporate_docs --chunk-size 1024 --overlap 200

# Важно: настраиваем обработку многоязычных документов
export ALEPH_MULTILINGUAL=true
export ALEPH_DEFAULT_LANGUAGES="ru,en,de,fr"

Патч для исходного кода, который вам пригодится. В файле aleph/processing/multilingual.py добавьте:

# Исправление для смешанных русско-английских документов
def detect_language_chunks(text, chunk_size=500):
    """Детектим язык для каждого чанка, а не всего документа"""
    chunks = [text[i:i+chunk_size] for i in range(0, len(text), chunk_size)]
    languages = []
    for chunk in chunks:
        # Приоритет русскому в смешанных документах
        if any(cyr_char in chunk for cyr_char in 'абвгдеёжзийклмнопрстуфхцчшщъыьэюя'):
            languages.append('ru')
        else:
            try:
                lang = detect(chunk)
                languages.append(lang)
            except:
                languages.append('en')
    return languages

Шаг 3: LibreChat - собираем интерфейс без дыр

LibreChat 1.8.3 умеет работать с локальными моделями из коробки. Почти. Нужно поправить конфигурацию:

# Клонируем репозиторий
git clone https://github.com/danny-avila/LibreChat
cd LibreChat
git checkout v1.8.3

# Создаём .env файл для локальной конфигурации
cat > .env << 'EOF'
MONGO_URI=mongodb://localhost:27017/librechat
JWT_SECRET=ваш-секретный-ключ-минимум-32-символа
ALLOW_REGISTRATION=false  # корпоративный портал!
APP_TITLE=Корпоративный AI Аналитик

# Конфигурация для LM Studio
LM_STUDIO_BASE_URL=http://ваш-lm-studio-сервер:1234/v1
LM_STUDIO_API_KEY=sk-не-нужен-для-локального

# Интеграция с Aleph RLM
ALEPH_RLM_URL=http://ваш-aleph-сервер:8000
ALEPH_API_KEY=корпоративный-ключ
EOF

Шаг 4: Соединяем всё в работающую систему

Типичная ошибка - забыть про таймауты. Документ на 100 страниц обрабатывается не 5 секунд. Настраиваем:

# docker-compose.yml для всего стека
version: '3.8'

services:
  librechat:
    image: ghcr.io/danny-avila/librechat:1.8.3
    ports:
      - "3000:3000"
    environment:
      - REQUEST_TIMEOUT=600000  # 10 минут!
      - MAX_CONTEXT_LENGTH=131072
    depends_on:
      - mongodb
      - lmstudio
      - aleph

  lmstudio:
    # Используем образ с CUDA поддержкой
    image: lmstudio/lmstudio:0.3.9-cuda12.1
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
    ports:
      - "1234:1234"
    volumes:
      - ./models:/models
      - ./lmstudio-config.json:/app/config.json

  aleph:
    image: alephdata/aleph-rlm:2.8
    ports:
      - "8000:8000"
    volumes:
      - ./corporate_docs:/data
    environment:
      - ALEPH_ARCHIVE_PATH=/data
      - ALEPH_PROCESS_TIMEOUT=300

  mongodb:
    image: mongo:7.0
    volumes:
      - ./mongo_data:/data/db

Проблемы, которые вас ждут (и как их решить)

Реальные кейсы использования

Юридическая фирма: анализирует 50+ договоров ежедневно, ищет рисковые формулировки. Система находит противоречия в условиях, которые человек пропускает.

Финансовый департамент: обрабатывает квартальные отчёты, выделяет ключевые метрики, сравнивает с предыдущими периодами. Всё локально, данные не выходят за периметр.

Техническая документация: инженеры загружают спецификации оборудования, AI ищет несоответствия между разделами, проверяет полноту информации.

Что делать, когда всё работает?

Настроить мониторинг. Prometheus + Grafana для отслеживания:

• Загрузка VRAM на LM Studio сервере
• Время обработки документов в Aleph RLM
• Количество активных пользователей в LibreChat
• Температуру GPU (да, это важно)

Регулярно обновлять модели. На 05.02.2026 вы используете Qwen2.5. Через полгода появится Qwen3.0 с лучшим пониманием контекста. Обновляйтесь, но тестируйте на тестовых документах перед переходом.

Альтернативы, если этот стек кажется сложным

Если не хотите возиться с тремя компонентами, посмотрите на Open Cowork - Rust-решение "всё в одном". Или локальные альтернативы Google NotebookLM для более простых задач.

Для запуска просто локальной модели без всей этой сложности есть Ollama vs другие решения. Но помните: для корпоративного анализа документов нужна именно такая комплексная система.

Итог: стоит ли овчинка выделки?

Стоит, если у вас больше 10 анализируемых документов в день. Стоит, если эти документы содержат коммерческую тайну. Стоит, если вы устали объяснять аудиторам, куда уходят данные.

Первые две недели - ад. Настройка, отладка, исправление таймаутов. Потом система работает месяцами без вмешательства. Вы загружаете документ, получаете анализ. Никаких подписок, никаких лимитов токенов, никаких утечек.

Последний совет: сделайте бэкап конфигурации. Все эти .env файлы, docker-compose.yml, патчи исходного кода. Когда через полгода придётся развернуть систему на новом сервере, вы скажете себе спасибо.