ОПИСАНИЕ АРХИТЕКТУРЫ
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ «АССИСТЕНТ ПРО»
Правообладатель: ИП Белоусов Дмитрий Владимирович (ИНН 665206580503)
Наименование ПО: Ассистент ПРО (RAG-система интеллектуального поиска и генерации ответов)
Дата документа: 28 апреля 2026 г.
Настоящий документ содержит описание архитектуры программного обеспечения «Ассистент ПРО» и подготовлен в соответствии с требованиями постановления Правительства Российской Федерации от 16 ноября 2015 г. № 1236 (в действующей редакции) для включения сведений о ПО в Единый реестр российских программ для электронных вычислительных машин и баз данных Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации.

1. Общие сведения о программном обеспечении
1.1. Наименование
Полное наименование: «Ассистент ПРО» — программное обеспечение в сфере искусственного интеллекта, реализующее технологию RAG (Retrieval-Augmented Generation, поиск с дополненной генерацией) на основе больших языковых моделей.
Условное обозначение в проектной документации, конфигурационных файлах и репозиториях исходного кода: sitellm_vertebro.
1.2. Назначение
Программное обеспечение предназначено для построения интеллектуальных корпоративных ассистентов (чат-ботов и голосовых аватаров), которые автоматически обрабатывают запросы пользователей в свободной форме на русском языке, извлекают релевантную информацию из корпоративной базы знаний и формируют осмысленные ответы на естественном языке с указанием источников.
Целевые отрасли применения: техническая поддержка, продажи, корпоративное обучение (e-learning), HR-сервисы, обработка обращений граждан в государственных органах и образовательных учреждениях, работа с обширными нормативно-методическими базами знаний.
1.3. Объём программного обеспечения
Совокупный объём кодовой базы (расчёт на момент формирования документа):
Кодовая база организована как монорепозиторий и логически разделена на 12 Python-модулей верхнего уровня, два веб-интерфейса (административная панель и встраиваемый чат-виджет), три клиента мессенджеров (Telegram, ВКонтакте, MAX) и набор интеграций с внешними системами.

2. Архитектурная модель
2.1. Общая концепция
ПО «Ассистент ПРО» построено на микросервисной модели, развёртываемой как единое приложение средствами Docker Compose. Каждый компонент изолирован в отдельном контейнере, имеет собственный интерфейс взаимодействия и может масштабироваться независимо. Внутренние коммуникации осуществляются через приватную сеть Docker bridge, внешние — только через явно проброшенные порты.
В основе работы лежит конвейер RAG: запрос пользователя → векторизация → гибридный поиск по корпоративной базе знаний → формирование расширенного промпта → генерация ответа большой языковой моделью → стриминг ответа клиенту в режиме Server-Sent Events.
2.2. Компонентная схема
Система состоит из следующих логических слоёв:

• Слой представления (Presentation): SPA-админка (раздел /admin), встраиваемый чат-виджет (/widget), клиенты мессенджеров (Telegram, VK, MAX).
• Слой публичных API (Public API): FastAPI-приложение, маршруты публичного доступа (/api/v1/llm, /api/v1/chat, /api/v1/voice, /api/v1/reading, /api/v1/feedback).
• Слой административных API (Admin API): защищённые маршруты /api/v1/admin/* с аутентификацией на уровне ASGI-middleware.
• Ядро интеллектуальной обработки (Core): модули поиска (packages/retrieval), генерации (packages/backend), обработки знаний (packages/knowledge).
• Слой данных (Data): MongoDB (документы, метаданные, диалоги, GridFS-хранилище файлов), Qdrant (векторное хранилище), Redis (кэш, брокер задач).
• Слой фоновых задач (Async): Celery worker и Celery beat — индексация, обновление эмбеддингов, обновление поисковых индексов, периодические резервные копии.
• Слой инференса моделей: Ollama Runtime (локальные GGUF-модели) и/или внешний LLM-микросервис (model-service) с REST-интерфейсом, обёртка backend.llm_client для унифицированного доступа.
• Слой коннекторов (MCP): протоколы Model Context Protocol для интеграций с Bitrix24, корпоративной электронной почтой (IMAP/SMTP) и иными корпоративными системами.

2.3. Топология рантайма
Стандартная схема Docker Compose разворачивает следующие сервисы:
Все запросы между сервисами выполняются по приватной сети Docker (driver: bridge). Внешний трафик принимается только сервисом app. Опционально перед app устанавливается обратный прокси Caddy/nginx с TLS-терминированием — соответствующая конфигурация автоматически создаётся скриптом scripts/bootstrap.sh при указании домена.

3. Использованные языки программирования
3.1. Python

• Версия: Python 3.10–3.12 (требование pyproject.toml: requires-python = ">=3.10,<3.13").
• Применение: backend FastAPI, обработка документов и векторизация, интеграция с LLM, фоновые задачи Celery, клиенты мессенджеров.
• Доля в кодовой базе: ≈ 66,6 %.

3.2. JavaScript / TypeScript

• Стандарт: ES6+, использование классов, модулей ESM, async/await.
• Применение: SPA-админка (vanilla JS, без фреймворков), встраиваемый чат-виджет.
• Доля в кодовой базе: ≈ 22,8 %.

3.3. HTML / CSS

• Применение: разметка веб-интерфейсов, стилизация (без UI-фреймворков, кастомные стили).
• Доля в кодовой базе: ≈ 10,7 %.

3.4. Языки разметки и конфигурации

• YAML — конфигурации Docker Compose (compose.yaml, compose.gpu.yaml, compose.override.yaml).
• TOML — конфигурация проекта (pyproject.toml).
• JSON — метаданные пакетов, конфигурации виджета, versions.json (хеши клиентов).
• Bash и PowerShell — скрипты автоматизации развертывания (scripts/bootstrap.sh, deploy_project.sh, deploy_project.ps1).

4. Системы управления базами данных
4.1. MongoDB

• Версия: MongoDB 8.0 (Community Edition, лицензия SSPL).
• Назначение: документная база для хранения метаданных проектов, документов базы знаний, истории диалогов, очередей операторских обращений, статистики, бэкап-настроек, а также бинарных файлов через GridFS.
• Драйверы: pymongo ≥ 4.13.2 (синхронный), motor ≥ 3.7.1 (асинхронный).

Основные коллекции:
4.2. Qdrant

• Версия: Qdrant latest (рекомендуется фиксация конкретной версии в продуктиве).
• Назначение: хранение векторных эмбеддингов (плотных представлений) текстовых фрагментов и поддержка векторного, BM25 и гибридного поиска.
• Транспорт: HTTP (порт 6333) и gRPC (порт 6334).
• Параметры коллекций: метрика расстояния — COSINE; payload-индексы по полям project, source, document_id; шардирование — на одном узле, на кластере выделяется отдельный коллекционный раздел на проект.
• Размерность векторов: определяется моделью эмбеддингов (для deepvk/USER-bge-m3 — 1024).

4.3. Redis

• Версия: Redis 7-alpine (для разработки), допускается bitnami/redis (production).
• Назначение: кэш результатов поиска (TTL 86400 с), брокер сообщений Celery, хранилище состояний краулера, технических сессий, метрик rate-limiting.
• Аутентификация: пароль через переменную REDIS_PASSWORD, протокол ACL включается в production-конфигурации.

5. Используемые фреймворки и библиотеки
5.1. Backend-фреймворки и сервисы
5.2. Библиотеки обработки документов
5.3. Библиотеки ИИ-стека
5.4. Frontend-стек

• Vanilla JavaScript (ES6+) — без UI-фреймворков; модульная архитектура SPA.
• vitest ≥ 1.6.0 — фреймворк модульного тестирования (dev-зависимость).
• @testing-library/dom, @testing-library/user-event, jsdom — тестирование DOM и пользовательских сценариев.

6. Модели машинного обучения и ИИ
6.1. Модели эмбеддингов
Основная модель эмбеддингов:

• Идентификатор: deepvk/USER-bge-m3 (репозиторий Hugging Face Hub).
• Тип: Sentence Transformer (BGE-M3-семейство), оптимизирован для русского языка.
• Размерность векторов: 1024.
• Поддержка длинного контекста: до 8192 токенов.
• Лицензия: Apache 2.0 (модель), MIT (библиотека).
• Развёртывание: возможна локальная загрузка модели в контейнер; кэш моделей монтируется как volume ./data/hf:/root/.cache/huggingface.

Альтернативные модели (поддерживаются конфигурацией): intfloat/multilingual-e5-large, sentence-transformers/paraphrase-multilingual-mpnet-base-v2, любая модель Sentence Transformers с совместимой размерностью.
6.2. Большие языковые модели (LLM)
Модель по умолчанию: Vikhrmodels/Vikhr-YandexGPT-5-Lite-8B-it (8 млрд параметров, инструктивная версия, GGUF-формат, размер ≈ 4,5 ГБ).
Дополнительно поддерживаются (через Ollama Runtime или совместимый API):
Перед коммерческим использованием каждой модели правообладатель проверяет совместимость её лицензии с внутренними политиками заказчика и требованиями российского законодательства. Все указанные модели запускаются локально на сервере заказчика (on-premise) либо в собственной инфраструктуре правообладателя на территории Российской Федерации; передача данных пользователей иностранным провайдерам в стандартной поставке отключена.
6.3. Модели поиска и переранжирования

• Гибридный поиск: формула Reciprocal Rank Fusion (RRF) с константой k = 60. Результаты dense-поиска (косинусное расстояние, top-50) и BM25-поиска (top-50) объединяются в единый ранжированный список (top-10 по итогу).
• Опциональный реранкер на базе cross-encoder (ms-marco-MiniLM-L-12-v2 или его русскоязычный аналог) — переоценка top-N результатов с учётом полного текста запроса и фрагмента.

7. Конвейер RAG (Retrieval-Augmented Generation)
7.1. Этап 1. Сбор и приём знаний

1. Загрузка документов через административную панель (форматы PDF, DOCX, DOC, TXT, XLSX, XLS, HTML, JSON, CSV, XML).
2. Автоматический обход сайта (web-краулер) с учётом robots.txt, поддержкой JavaScript-рендеринга через опциональный Playwright и дедупликацией URL.
3. Импорт пар «вопрос — ответ» (Q&A) — ручной ввод, импорт CSV.
4. Получение писем по IMAP и обращений из Bitrix24 — сообщения автоматически могут пополнять базу знаний (если включено правилами проекта).

7.2. Этап 2. Извлечение и нормализация текста
Каждый документ обрабатывается соответствующим лоадером: pypdf для PDF, docx2txt для DOCX, openpyxl для XLSX, BeautifulSoup для HTML. Текст очищается от служебной разметки, нормализуется кодировка (нормализация в NFC/NFKC), удаляются повторяющиеся элементы (шапки, навигация). Результат — очищенный плоский текст и сохранённый исходный файл в GridFS.
7.3. Этап 3. Сегментация и эмбеддинг
Очищенный текст сегментируется на смысловые фрагменты заданной длины (по умолчанию — параграфы или окна по 800 символов с перекрытием 200). Каждый фрагмент пропускается через модель эмбеддингов (deepvk/USER-bge-m3) и преобразуется в вектор размерности 1024. Векторы сохраняются в Qdrant вместе с payload-полями (project, source, document_id, fragment_index, text-фрагмент-сниппет).
7.4. Этап 4. Гибридный поиск (Retrieval)
При поступлении запроса пользователя:

1. Запрос векторизуется тем же эмбеддером.
2. В Qdrant параллельно выполняется dense-поиск (top-50) по косинусной близости и BM25-поиск (top-50) по полнотекстовому индексу.
3. Результаты объединяются по формуле RRF: score(d) = Σ 1/(k + rank_i(d)) для каждого источника-метода (k = 60).
4. Опционально: top-20 кандидатов передаются в cross-encoder реранкер для уточнения релевантности.
5. Финальный список (top-10) передаётся в этап генерации.

Результаты поиска кэшируются в Redis по ключу sha1(project + query) с TTL 24 часа, что снижает нагрузку при повторяющихся запросах.
7.5. Этап 5. Формирование промпта и генерация
Из найденных фрагментов формируется контекст (по умолчанию — 3 наиболее релевантных, ≈ 300 символов каждый), который вместе с исходным вопросом и системным шаблоном проекта подаётся в выбранную LLM (Ollama, model-service или внешний шлюз). Системный шаблон проекта задаётся администратором в разделе Projects и определяет тон, стиль, обязательные инструкции (например, отвечать только по корпоративным данным, цитировать источники, отказывать в случае отсутствия информации).
7.6. Этап 6. Стриминг ответа
Ответ возвращается пользователю в режиме потоковой передачи Server-Sent Events (SSE) через эндпойнт GET /api/v1/chat. Это обеспечивает мгновенную обратную связь и совместимо с веб-виджетами и нативными ботами. По завершении генерации к ответу прикрепляется список источников (Citation) с прямыми ссылками на исходные документы либо страницы сайта.
7.7. Этап 7. Постобработка и обратная связь

• Безопасностный фильтр (safety/filter.py) проверяет ответ на наличие чувствительных паттернов (прежде всего — нежелательные медицинские рекомендации, сомнительные дозировки) и при необходимости подменяет ответ на безопасный шаблон.
• Пользователь может оценить ответ (👍/👎) через эндпойнт POST /api/v1/feedback; оценки агрегируются для последующего улучшения базы знаний и промптов.
• Запросы, на которые система не нашла релевантного ответа, фиксируются в коллекции unanswered и доступны администратору для дополнения базы знаний.

8. Подсистемы и сервисы
8.1. Подсистема обработки документов
Реализована в packages/knowledge. Включает: лоадеры по форматам, очиститель текста, генератор кратких описаний (на базе LLM), Celery-задачи фоновой переиндексации, сервис автоматического обогащения метаданных (knowledge_service).
8.2. Подсистема веб-краулинга
Реализована в packages/crawler. Поддерживает: ограничение глубины и количества страниц, белый/чёрный список путей, дедупликацию по нормализованному URL и хешу содержимого, инкрементальный обход (crawl-since), отчёты о прогрессе через Redis. Управляется через эндпойнты /api/v1/crawler/run, /status, /reset, /stop, /deduplicate.
8.3. Подсистема диалогов
Реализована в apps/api/main.py (модуль llm) и в виджете /widget. Поддерживает: сессии (session_id в query), хранение контекста диалога в Redis с TTL, передачу истории сообщений в промпт LLM (последние N сообщений, настраивается параметром проекта), переадресацию оператору (Operator Mode).
8.4. Подсистема голосового ввода и обучения голоса
Реализована в apps/api/main.py (модуль voice) и в Celery-задачах apps/worker. Позволяет загружать голосовые образцы (POST /api/v1/voice/samples), запускать обучение голосовой модели (POST /api/v1/voice/train), отслеживать статус задач (/voice/status, /voice/jobs).
8.5. Подсистема резервного копирования
Реализована в packages/utils/backup. Использует mongodump для создания архивов MongoDB, поддерживает локальное хранение и выгрузку на Яндекс.Диск (через REST API). Расписание управляется Celery beat (по умолчанию проверка каждые 300 с, фактическое создание архива — по cron-расписанию, заданному в backup_settings). Эндпойнты: GET /backup/status, POST /backup/run, POST /backup/restore, POST /backup/settings.
8.6. Подсистема наблюдаемости

• Структурированное логирование structlog в формате JSON с уровнями DEBUG/INFO/WARNING/ERROR.
• Метрики Prometheus: request_count (Counter, метки method, path), error_count (Counter, метка path), latency_ms (Histogram). Экспозиция — /metrics.
• Healthchecks: GET /healthz, GET /health (быстрые), внутренние проверки lifespan для MongoDB/Redis/Qdrant/Ollama.
• Журнал последних событий доступен администратору через GET /api/v1/admin/logs; статистика запросов — через /api/v1/admin/stats/requests с экспортом CSV.

8.7. Подсистема интеграций

9. Аутентификация и разграничение доступа
9.1. Модель доступа
Реализована парольная аутентификация на основе HTTP Basic + сессий. Все маршруты /admin (UI) и /api/v1/admin/* (API) защищены ASGI-middleware BasicAuthMiddleware (apps/admin/main.py). Открытые маршруты (/api/v1/chat, /api/v1/llm, /api/v1/feedback, /widget, /metrics при ограничении сетью) аутентификации не требуют — это публичные точки входа для конечных пользователей.
9.2. Уровни доступа
9.3. Хранение паролей
Пароли локальных учётных записей хранятся в коллекции projects (поле admin_password_hash) в виде хеша SHA-256 (в дальнейшем планируется миграция на bcrypt/argon2). Сравнение выполняется HMAC-безопасным методом (hmac.compare_digest), что исключает утечку информации через тайминговые атаки.
9.4. Сессии и завершение работы
Сессия администратора создаётся после успешной аутентификации и действительна до явного выхода (POST /api/v1/admin/logout) или истечения таймаута. Бэкап-токены, токены ботов и API-ключи хранятся в зашифрованном виде на уровне приложения; передача учётных данных между компонентами — через переменные окружения и приватную сеть Docker.

10. Безопасность и защита от прикладных рисков
10.1. Валидация входных данных
Все REST-эндпойнты используют Pydantic-модели для валидации входных параметров; неподходящие запросы отбрасываются с возвратом HTTP 422 (Unprocessable Entity). Загружаемые файлы проверяются по MIME-типу и размеру (лимит — 50 МБ по умолчанию, настраивается).
10.2. Фильтр промпт-инъекций и небезопасных ответов
Модуль safety/filter.py выполняет эвристическую проверку запросов и ответов: список запрещённых ключевых слов (включая медицинские рекомендации с указанием конкретных дозировок и наименований препаратов), регулярные выражения на типовые шаблоны попыток обхода системного промпта. При срабатывании фильтра ответ заменяется на безопасный шаблон, инцидент фиксируется в логах.
10.3. Транспортная безопасность

• Поддержка TLS 1.2/1.3 средствами Uvicorn (переменные APP_ENABLE_TLS, APP_SSL_CERT, APP_SSL_KEY).
• Альтернатива — обратный прокси Caddy с автоматическим выпуском сертификатов Let's Encrypt (настраивается scripts/bootstrap.sh при указании домена).
• Внутренний трафик — в приватной сети Docker bridge; внешний — только через явно проброшенные порты.

10.4. CORS
Конфигурация Cross-Origin Resource Sharing управляется переменной CORS_ORIGINS (.env). По умолчанию разрешены все источники (для удобства разработки), в production-конфигурациях обязательно ограничивается перечнем доменов заказчика.
10.5. Аудит и журналирование

• Все аутентификационные события (успех/неудача), действия с конфигурацией, операции загрузки/удаления документов, запуска краулера и резервного копирования логируются с указанием subject (учётная запись), action, object, timestamp, ip-адрес.
• Журналы доступны через GET /api/v1/admin/logs и могут экспортироваться во внешние SIEM-системы по syslog/JSON.

10.6. Соответствие требованиям персональных данных
ПО разворачивается на инфраструктуре заказчика и не отправляет данные пользователей за пределы периметра без явного согласия. При использовании внешних LLM-API администратор обязан убедиться в наличии локализованного шлюза (например, размещённого в РФ) и заключённых соглашениях об обработке данных. По умолчанию рекомендуется конфигурация on-premise на отечественной инфраструктуре.

11. Развёртывание, контейнеризация и инфраструктура
11.1. Контейнеризация
Используется Docker Compose v2.20+. Каждый компонент (FastAPI-приложение, Celery worker, Celery beat, Telegram-bot) собирается из общего Dockerfile с использованием многоэтапной сборки (multi-stage build):

• Этап build: образ python:3.10-slim, установка системных пакетов (build-essential, git, cmake, ninja-build, pkg-config, libopenblas-dev, python3-dev), разрешение зависимостей менеджером uv, копирование исходного кода, прекомпиляция в байт-код (python -m compileall).
• Этап runtime: минимальный набор пакетов (libopenblas0-pthread, curl, ca-certificates, MongoDB Database Tools), копирование готового байт-кода и виртуального окружения из этапа build.
• Кэши APT, UV и Hugging Face используются для ускорения повторных сборок.

11.2. Системные требования
11.3. Лимиты ресурсов на контейнеры
11.4. Скрипты автоматизации

• scripts/bootstrap.sh — установка Docker Engine, Docker Compose, настройка systemd-сервиса, опциональный Caddy-прокси, генерация .env, первичный запуск.
• deploy_project.sh — обновление существующего развертывания (git pull → docker compose build → docker compose up).
• deploy_project.ps1 — аналог для Windows-сред.
• scripts/healthcheck.sh — внешний скрипт мониторинга, проверяет TLS и доступность API.
• scripts/benchmark.py — нагрузочный бенчмарк p50/p95-латентности.

11.5. Масштабируемость

• Горизонтальное масштабирование сервиса app — путём запуска нескольких экземпляров за обратным прокси (Caddy/nginx).
• Несколько Celery worker — добавляются простой репликой контейнера.
• Кластеризация Ollama — поддержана в backend/ollama_cluster.py: автоматическая балансировка между несколькими нодами, мониторинг здоровья, fail-over.
• Шардирование Qdrant — выполняется на уровне коллекций (по проектам).

12. Отнесение ПО к программному обеспечению в сфере искусственного интеллекта
12.1. Применённые методы и алгоритмы ИИ
В составе ПО реализованы следующие технологии искусственного интеллекта:

• Глубокое обучение — нейросетевые модели на архитектуре Transformer применяются для построения векторных представлений текстов (модель deepvk/USER-bge-m3) и для генерации ответов (модели Vikhr-YandexGPT, Llama 3.1, Mistral, Qwen и иные совместимые большие языковые модели).
• Обработка естественного языка (NLP) — токенизация, нормализация, сегментация текстов, ответ на вопросы (Question Answering) на естественном языке.
• Информационный поиск с применением машинного обучения — гибридный поиск, объединяющий нейросетевой dense-поиск и алгоритмический BM25 через формулу RRF; опциональное переранжирование cross-encoder.
• Генеративные модели — Retrieval-Augmented Generation: генерация осмысленного, контекстно-зависимого текста на основе извлечённых фрагментов знаний.
• Распознавание речи (Speech Recognition) — опциональная функциональность, реализуемая через интеграцию с внешними или встроенными моделями ASR (Whisper-совместимыми).

12.2. Соответствие классификатору Минцифры
ПО соответствует следующим разделам Классификатора программ для электронных вычислительных машин и баз данных, утверждённого Приказом Минкомсвязи / Минцифры РФ от 22.09.2020 № 486 (в действующей редакции):
12.3. Обоснование статуса проекта в сфере ИИ
Программное обеспечение реализует полноценный цикл ИИ-обработки: от сбора данных и обучаемой векторизации текстов до генерации ответов с помощью больших языковых моделей. Качество работы измеряется типичными для систем искусственного интеллекта метриками: recall@k, точность ответа (по экспертной оценке и оценкам пользователей), доля «галлюцинаций» (нерелевантных или вымышленных утверждений), средняя длина и связность ответов. Все эти признаки соответствуют критериям отнесения ПО к категории искусственного интеллекта в понимании ПП РФ № 1236 и приказов Минцифры.

13. Открытое программное обеспечение и лицензии зависимостей
В составе ПО используются компоненты с открытым исходным кодом со следующими лицензиями:
Все используемые библиотеки и модели — это компоненты, исходные тексты которых опубликованы в общедоступных репозиториях; их применение не создаёт зависимости от иностранных правообладателей в части эксплуатации (отсутствует обязательное обращение к зарубежным сервисам).

14. Тестирование и обеспечение качества
14.1. Уровни тестирования
14.2. CI/CD
Используются GitHub Actions (.github/workflows/ci.yml) и GitLab CI (на серверах правообладателя — office1.mmvs.ru:8929). Pipeline включает: установку зависимостей через uv, запуск Ruff, запуск pytest -q, бенчмарк с регрессионным гейтом по p95-латентности.

15. Каталог исходного кода
Дерево проекта верхнего уровня (фрагмент):
sitellm_vertebro/
├── apps/
│   ├── admin/            # FastAPI-приложение, админ-панель (~6,4 тыс. строк)
│   │   ├── main.py
│   │   └── index.html
│   ├── api/              # Публичные роутеры (~2,7 тыс. строк)
│   │   └── main.py
│   └── worker/           # Celery worker
│       └── main.py
├── packages/
│   ├── backend/          # settings, llm_client, ollama, ollama_cluster, prompt, cache, model_service
│   ├── core/             # mongo, models, settings, status, vectors, build, textnorm
│   ├── crawler/          # run_crawl.py + Celery-задачи
│   ├── retrieval/        # hybrid search, rerank, embedder
│   ├── knowledge/        # извлечение текста, summary, авто-описание
│   ├── knowledge_service/# фоновый сервис обогащения эмбеддингов
│   ├── utils/            # observability (logging, metrics), backup
│   └── common/           # shared schemas + services
├── connectors/           # MCP-серверы (bitrix24, email)
├── integrations/         # bitrix.py, mail.py (legacy слой)
├── tg_bot/, vk_bot/, max_bot/   # клиенты мессенджеров
├── widget/               # встраиваемый чат-виджет
├── safety/               # фильтр запрещённых паттернов
├── scripts/              # bootstrap, deploy, healthcheck, benchmarks
├── tests/                # pytest, ≈ 48 файлов
├── docs/                 # Sphinx + Markdown (architecture, workflows)
├── compose.yaml          # основная конфигурация Docker Compose
├── Dockerfile            # multi-stage сборка backend
├── pyproject.toml        # манифест Python-проекта
└── uv.lock               # детерминированные версии зависимостей
Документ содержит сведения, достаточные для проведения экспертной проверки в порядке, установленном Постановлением Правительства Российской Федерации от 16 ноября 2015 г. № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд» (в действующей редакции).