Как подключить LLM к 1С без переписывания 1С

Данные сначала: три признака, что ваша 1С не готова к LLM

LLM понимает запрос на естественном языке, но ответ строит по тем строкам, которые находит в справочниках и регистрах. Если в базе три карточки одного контрагента — «ООО Ромашка», «Ромашка ООО» и «Ромашка (поставщик)» — агент сложит обороты механически и выдаст задвоенную маржу. Руководитель увидит искажённую картину и потеряет доверие к инструменту.

Три маркера, которые говорят: прежде чем звать ИИ, наведите порядок.

• Дубли контрагентов и номенклатуры. Одна компания или товар заведены несколько раз, и каждый счёт-фактура привязан к разному элементу. Агент не умеет определять эквивалентность без явного маппинга.

Минимальный шаг: провести дедупликацию встроенными средствами 1С или через внешний обработчик, оставить один основной элемент.

• Незаполненные аналитики. Статья движения денег не указана, подразделение пустое. На вопрос «покажи выручку по региону» агент обнаружит пробелы и либо вернёт неполные цифры, либо придумает (галлюцинирует) обобщение.

Минимальный шаг: до запуска пилота заполните обязательную аналитику хотя бы по 3–5 ключевым справочникам, которые фигурируют в типовых вопросах.

• Ручные корректировки без комментариев. Обороты сторнированы оператором вручную, но причина не записана в поле «комментарий». Агент видит расхождение и не может объяснить его руководителю — не хватает контекста.

Минимальный шаг: требуйте, чтобы ручные операции сопровождались коротким текстовым комментарием в карточке документа, доступным через тот же OData.

Две недели на очистку сэкономят месяцы разбирательств с «почему он ошибается».

Три архитектуры: какая подходит вашему бизнесу

Когда данные приведены в порядок, появляется выбор: как именно агент будет получать информацию из 1С. Способ определяет, насколько ответы будут актуальными, сколько ресурсов потребует поддержка и как быстро вы увидите первый результат.

OData REST — самый быстрый старт. 1С умеет отдавать справочники и регистры в формате JSON через встроенный интерфейс OData. Вы публикуете нужные объекты, ограничиваете доступ только на чтение и пропускаете запросы через API-шлюз с ограничением частоты. Руководитель пишет запрос на естественном языке, LLM формирует OData-запрос, получает цифры и собирает ответ. Пример: «Сколько составила дебиторская задолженность контрагентов из Москвы на утро вторника?» — агент отправляет $filter=Region eq 'Москва' и возвращает таблицу с источником записей. Этот путь используют для пилотов, где важна скорость и актуальность, но без сознательной настройки легко перегрузить рабочую базу ERP.

ETL + RAG — безопасно, если нужна история. Данные копируются в отдельную аналитическую БД (ClickHouse, PostgreSQL + pgvector), индексируются и становятся доступны через привычный механизм RAG (Retrieval-Augmented Generation). Вы не задеваете продакшн-контур, можете хранить историю за пять лет и обогащать модель контекстом. Плата — задержка: агент не видит движения, произошедшие после последней выгрузки. Подходит для регулярной отчётности: «Какие SKU росли по марже последние три месяца?»

MCP-сервер — агент сам вызывает функции 1С. Model Context Protocol (MCP) позволяет описать любой метод базы как инструмент, который LLM может дёргать в реальном времени. Сервер-посредник принимает запрос от агента, выполняет функцию внутри 1С и возвращает результат. Доработка конфигурации не требуется — достаточно установить сервер (например, открытый mcp-1c с 40+ релизами). Руководитель говорит: «Сформируй счёт для контрагента Икс по последнему договору». Агент сам находит договор, подставляет реквизиты и создаёт черновик документа — всё через MCP. Это осмысленно, когда бизнес-сценарий предполагает не только чтение, но и действия в системе.

Что вы получите: сценарий «до» и «после»

Представьте: ежемесячно финансовый директор запрашивает у аналитика отчёт «Топ-10 клиентов по маржинальной прибыли за прошедший месяц». Аналитик вручную выгружает данные из 1С:Управление торговлей, сводит в Excel, проверяет корректность справочников и возвращает результат через два дня. Если директору нужен свежий срез на позавчера — цикл повторяется.

С подключением LLM через OData REST этот же запрос обрабатывается иначе. Руководитель пишет в чат-интерфейс: «Покажи топ-10 клиентов по марже за июль». Агент отправляет OData-запрос к регистру «ПродажиСебестоимость», получает строки с аналитикой по контрагентам, фильтрует период, вычисляет маржу и возвращает ответ:

«Топ-10 клиентов по марже за июль: 1. ООО "Стройком" — 4,2 млн руб. (маржинальность 34%) 2. ИП Петров А.В. — 3,8 млн руб. (29%) ... Источник: данные регистра "Продажи" УТ 11.4 на 10:15 (OData).»

Аналитик больше не делает выгрузку руками; его работа смещается на проверку сложных кейсов и анализ причин отклонений. Время получения ответа сокращается с двух дней до 40 секунд. Конкретный процесс — подготовка регулярной управленческой сводки — перестал быть узким горлышком.

Это не гипотетический пример. В анонимном кейсе российской розничной компании интеграция LLM с 1С:УТ 11.4 через REST API сократила время обработки возвратов с 42 до 6 минут при снижении нагрузки на операторов на 80% источник: Habr. Схожий механизм — только вопрос не операционный, а управленческий — заработает и для аналитики по первому требованию.

Метрики пилота: что мерить на неделе 1 и месяце 1

Первый вопрос после запуска — работает ли агент в реальных условиях. Утверждение «отвечает» недостаточно: нужны цифры, которые разрешат или остановят масштабирование.

Неделя 1 — функциональный тест. Вы даёте агенту 20 заранее подготовленных вопросов, ответы на которые известны. Фиксируете:

• Долю запросов, на которые агент ответил без эскалации к аналитику (цель первой недели — >70%).
• Количество галлюцинаций — ответов с неверным или выдуманным источником. Ловите их, сверяя цифру в ответе с прямым запросом к 1С через OData или UI. Ведите лог: запрос → сгенерированный ответ → фактическое значение.

Месяц 1 — рабочий контур. Расширяете круг пользователей до 3–5 человек, которые задают реальные вопросы по ходу дня. Считаете:

• Покрытие: доля запросов, которые агент может обработать, от общего числа обращений (целевой ориентир — >60% к концу месяца, остальное — эскалация).
• Среднее время ответа агента против времени ожидания стандартного отчёта от ИТ. Разница между 40 секундами и 16 часами говорит сама за себя.
• Нагрузку на боевую базу: количество API-запросов в час и среднее время отклика OData-эндпоинта до и после включения агента. Рост задержки больше чем на 20% — сигнал к ревизии rate limiting.

Эти метрики превращают пилот из «технологии ради технологии» в обоснование бизнес-решения. Если за месяц агент стабильно отвечает на две трети вопросов и не роняет ERP, вы готовы к расширению скоупа.

Безопасность: облако или своё железо?

В корпоративной среде РФ вопрос, где физически работает модель, влияет на запуск сильнее, чем выбор архитектуры. LLM можно развернуть двумя способами:

• Облачное API (YandexGPT, GigaChat API). Данные запроса и контекст уходят за периметр компании. Подходит для пилотов на обезличенных или нечувствительных данных, но для бухгалтерских регистров требует одобрения службы безопасности.
• On-premise (GigaChat on-premise, YandexGPT Private, или open-source модель на сервере компании). Модель работает внутри контура, данные не покидают организацию. Затраты выше, но для производственных цифр 1С это даёт зелёный свет без дополнительных согласований.

Выбор решается до старта пилота. Если компания уже использует облачную модель для других задач, OData-пилот можно запустить в том же окружении. Если нет — начинайте с локального развёртывания санкционированной инференс-машины. Тогда архитектура наслаивается поверх защищённого канала, и весь процесс укладывается в корпоративные политики.

Без переписывания 1С, без найма ML-команды и без остановки процессов: путь к работающему агенту лежит через аудит данных, выбор архитектуры под свою задачу и несколько цифр на первой неделе. Начните с трёх вопросов к вашей учётной системе — и на втором шаге вы уже получите ответ на естественном языке, который будет стоить тех 40 секунд, что отделяют его от двухдневного ожидания.