Автоматический поиск документов из 1С:ДО

Обратились с запросом: дать сотрудникам возможность спрашивать по архиву 1С:Документооборот обычным языком — какая актуальная версия документа, что менялось между редакциями, как шло согласование и что ответить на комментарий, — с точными ссылками на документы и без выдумок.

Это AI/RAG-пилот поверх боевой базы 1С:Документооборот КОРП 3.0: система регулярно выгружает документы, версии, согласования, подписи, переписку и связи через OData, складывает их в собственный каталог на PostgreSQL, индексирует в Qdrant и отвечает на вопросы через локальную LLM. Прямого доступа к базе 1С нет по условиям заказчика — весь обмен идёт только через OData-публикацию, поэтому конвейер выгрузки построен как отдельный отказоустойчивый контур с инкрементом, повторами и блокировками. Развёртывание on-prem на оборудовании заказчика: Docker Compose и Kubernetes-манифесты, локальные модели эмбеддингов и LLM — данные не покидают контур.

• Бэкенд на FastAPI (Python 3.12) с асинхронным PostgreSQL (asyncpg/SQLAlchemy), миграциями Alembic и JWT-авторизацией
• OData-клиент к 1С:ДО КОРП 3.0: постраничная выгрузка, retry, чтение $metadata, поимённый выбор полей вместо полной карточки
• Маппинг сущностей 1С:ДО в собственный каталог: документы, версии файлов, согласования, комментарии, подписи, контрагенты, проекты, связи
• Полнотекст версий из регистра «ТекстыВерсийФайлов» (бинарь файла OData не отдаёт) плюс извлечение текста из PDF/DOCX/TXT
• Процессы и задачи 1С (9 видов бизнес-процессов и задачи исполнителей) → шаги маршрута согласования, резолюции и результаты задач в истории документа
• Переписка: входящие и исходящие письма становятся документами каталога со связями «переписка» и «ответ на письмо», вложения — версиями
• Связи документов из регистра «СвязиОбъектов» с именем типа связи из 1С — так в выдачу попадают претензии, доп. соглашения и акты к договору
• Инкрементальная синхронизация по DataVersion (ChangeTracking OData), полная — по деплою и ручному запуску; идемпотентность по onec_ref
• Планировщик выгрузки в отдельном процессе-воркере (APScheduler, ночной cron) под Postgres advisory lock — параллельные прогоны исключены
• Отказоустойчивость выгрузки: 404 и таймауты чтения не валят прогон, фазовые commit каталога, журнал служебных событий EventLog
• Индексация в Qdrant с payload-фильтрами (тип документа, контрагент, актуальная версия, вид фрагмента) и инкрементальной переиндексацией по index_hash
• Гибридный поиск: dense-эмбеддинги и BM25 со слиянием RRF, затем reranking cross-encoder’ом jina-reranker-v2-base-multilingual
• Точный поиск по регистрационному номеру через PostgreSQL, а не через эмбеддинги; полнотекстовый поиск по русскому словарю (FTS и GIN-индексы, подсветка)
• RAG-пайплайн с тремя промптами под сценарии, запретом галлюцинаций и раскрытием уточняющих вопросов перед поиском
• Автоопределение сценария LLM-классификатором — единый чат вместо ручного переключения вкладок
• Диалоговый контекст на сервере: уточняющая реплика раскрывается в полный запрос перед поиском
• Роли и права: доступ к сценариям и фильтрация выдачи по типам документов в поиске, FTS, карточке и графе; служебные ручки — только администратору
• Веб-интерфейс на React + TypeScript + Vite: чат со стримингом ответа (SSE), блок найденных документов, история запросов, копирование черновика
• Карточка документа: реквизиты, таймлайн версий, согласования с цветом решений, подписи, комментарии, связанные документы
• Граф связей на React Flow: документ ↔ версии ↔ согласования ↔ комментарии ↔ связанные документы
• Наблюдаемость: метрики Prometheus /metrics, статус индексации /ingest/status, журнал обращений с request_id, rate limiting
• Автооценка качества: контрольный набор из 27 кейсов с отчётом по точности и латентности плюс 5 negative-кейсов на анти-галлюцинации
• Развёртывание: Docker Compose и Kubernetes-манифесты (namespace, config, secret-шаблон, postgres, qdrant, api с миграциями, frontend, ingress), скрипты бэкапа и восстановления

• Ответ только по документам заказчика: если данных в индексе нет — система прямо говорит об этом, а не сочиняет
• Ссылки на источники в каждом ответе: конкретный документ, редакция и фрагмент, из которого взята формулировка
• Гибрид смысла и реквизитов: BM25-канал ловит точные номера договоров, dense-канал — формулировки «по смыслу», RRF сводит их вместе
• Дифф редакций как источник: на вопрос «что изменилось» отвечаем сравнением текстов версий, а не служебным комментарием из 1С
• Связи вместо совпадений: претензия или доп. соглашение не содержат номера головного договора — они находятся только через регистр связей 1С
• Единый чат с автомаршрутизацией: сценарий определяется классификатором, ручной фильтр источников при этом сохранён
• Уточняющие вопросы при неоднозначности: контрагент → документ → ответ, вместо выдачи наугад
• Полностью локальный контур: эмбеддинги и LLM — модели заказчика, без внешних API, архив не покидает периметр
• Работа без доступа к БД 1С: только OData-публикация, с обходом её ограничений — пачки or, лимит bind-параметров, отсутствие бинарей
• Устойчивость к сбоям 1С: таймаут или 404 на части сущностей не рушит прогон и не приводит к ложному удалению данных из каталога
• Ролевая видимость: запрещённый роли вид документа не появится ни в поиске, ни в графе, ни по прямой ссылке
• Готовность к on-prem: одинаково разворачивается Compose’ом на одном сервере и в Kubernetes у заказчика