Назад
Попросить AI-агента посчитать продажи за месяц уже несложно. Сложности начинаются, когда вслед за первым вопросом появляются десятки других: сравнить периоды, объяснить падение маржи, проверить остатки и сопоставить выручку с себестоимостью. Если агент каждый раз обращается напрямую к рабочей базе 1С, аналитика начинает конкурировать за ресурсы с оперативным учётом.
На вебинаре «LLM + OData + 1С: выдержит ли рабочая база AI-аналитику?», состоявшемся 1 октября 2026 года, технический директор «Денвик Аналитики» Степан Пыстин разобрал путь от прямых запросов к 1С через OData до отдельного контура данных с инкрементальной выгрузкой, ClickHouse и управлением через MCP. Разбираем техническую механику этого подхода и результаты показанной демонстрации.
Представим обычный сценарий: руководитель пишет агенту «Посчитай сумму продаж за октябрь». Агент находит подходящие объекты 1С, запрашивает записи реализации, получает данные, вычисляет итог и возвращает таблицу или график. Пользователю не нужно разбираться в структуре базы и писать запрос самостоятельно.
Для такого взаимодействия в 1С можно опубликовать стандартный интерфейс OData. Информационную базу размещают на веб-сервере с компонентами 1С, включают автоматический REST-сервис и указывают состав доступных объектов. Затем клиент обращается к опубликованному URL и получает машиночитаемый ответ, например JSON. С помощью параметров запроса можно выбрать поля, задать фильтр и ограничить выдачу.
Уже на этапе публикации необходимо настроить аутентификацию, HTTPS и минимальные права. Для аналитического сценария разумен доступ только на чтение. Сам факт наличия URL не делает сервис безопасным для размещения в открытом интернете.
Первая проверка обычно отвечает на вопрос «Может ли агент получить данные?». Для эксплуатации важнее следующий: «Что произойдёт, когда запросы станут регулярными, разнообразными и одновременными?»
Сегодня агент скачал реализации за месяц. Завтра его попросят сравнить год с предыдущим, затем рассчитать средний чек, а после – проверить оборачиваемость и остатки. Меняются периоды, источники и состав полей. Если на каждый запрос агент заново читает продуктивную базу, одна и та же история извлекается многократно.
У рабочей 1С в это время собственные задачи: проведение документов, расчёты, работа пользователей и регламентные операции. Частые небольшие обращения способны создавать конкуренцию за ресурсы; один тяжёлый запрос может надолго занять процессор, дисковую подсистему или соединения. Поэтому оценивать нужно одновременно частоту запросов, их стоимость, объём читаемых данных и время выполнения.
Следующий естественный шаг – развернуть отдельную СУБД, например ClickHouse, и поручить агенту подготовить скрипт периодической загрузки из OData. Аналитические запросы в таком случае выполняются уже в хранилище. Это снимает часть повторной нагрузки, но оставляет нерешённой задачу обновления: как быстро и без полного перечитывания определить, что изменилось в 1С?
Инкрементальная загрузка предполагает, что сначала переносится исторический массив, а дальше – только новые, изменённые и удалённые данные. Для произвольного набора объектов 1С стандартный OData не предоставляет единого готового журнала всех изменений, который можно просто запросить «с момента предыдущей выгрузки». Логику обнаружения различий приходится проектировать отдельно.
Для документов скользящее окно кажется практичным решением. Можно каждый день перечитывать текущий месяц и часть предыдущего. Но бухгалтерия иногда исправляет документы более ранних периодов. Если дата документа осталась прежней и вышла за границу окна, корректировка не попадёт в хранилище. Дата документа сама по себе не равнозначна времени последнего изменения.
Со справочниками ситуация другая. Допустим, в номенклатуре сотни тысяч элементов. Вместо полного чтения всех атрибутов можно запросить идентификаторы и DataVersion, сравнить их с предыдущим состоянием и догрузить изменённые карточки. Передаваемых реквизитов меньше, но саму проверку большого набора выполнять всё равно нужно.
С регистрами сложнее. Записи движений могут зависеть от проведения или изменения документа-регистратора. При обновлении регистратора иногда требуется заново получить соответствующий набор движений, включая случай, когда прежняя запись больше не должна присутствовать в аналитической таблице. Простое добавление новых строк здесь легко приводит к двойному учёту.
Отдельный вопрос – физическое удаление и пометка на удаление: эти состояния нельзя автоматически считать одинаковыми. Правила отражения обоих событий в аналитическом приёмнике должны быть определены заранее.
На вебинаре обсуждались условные объёмы в 100–300 тысяч записей, при которых полное обновление ещё может оказаться приемлемым, и гораздо более крупные массивы, где его стоимость резко возрастает. Это ориентиры для обсуждения архитектуры, а не установленный технический лимит OData. Реальная граница зависит от объектов, фильтров, платформы, СУБД, оборудования, конкурентной нагрузки и требований к актуальности.
Если для выгрузки требуется сегментация, контроль версий, обработка удалений, повторные попытки, преобразование типов, расписание и мониторинг, вокруг простого API постепенно возникает самостоятельная интеграционная система. AI-агент способен помочь написать её скрипты. Но сгенерированный код придётся тестировать, сопровождать и проверять на корректность после изменений конфигурации 1С. Иначе команда получает набор процедур, чьи ошибки обнаруживаются уже в управленческих отчётах.
В показанном на вебинаре решении за извлечение отвечает Экстрактор 1С – расширение, установленное в информационной базе. Он позволяет выбрать источник, поля и приёмник, организовать историческую выгрузку и последующее инкрементальное обновление. В отличие от внешнего опроса через OData, механизм регистрации изменений работает на стороне 1С, используя события объектов и информацию о регистраторах.
Сначала крупный исторический объём разбивается на сегменты – например, по датам или другим признакам, подходящим выбранному объекту. Сегменты обрабатываются отдельными порциями, при необходимости параллельно. Размер пачки и количество потоков настраиваются с учётом производительности источника и приёмника. Максимальная параллельность без контроля может сама создать избыточную нагрузку на 1С.
После первичной загрузки Экстрактор регистрирует события изменения и формирует очередь заданий. В очереди фиксируется, какой объект или связанный набор данных необходимо обновить; для каждой операции не требуется хранить копию всей исторической таблицы. По расписанию обработчик получает актуальное состояние и отправляет его в приёмник.
Такой подход уменьшает число повторных чтений неизменившейся истории. При этом производительность и задержка остаются эксплуатационными характеристиками, которые необходимо измерять в конкретной информационной базе.
В демонстрации использовался регистр выручки и себестоимости, движения которого связаны с документами реализации. Спикер изменил документ реализации товаров и услуг. Экстрактор зарегистрировал событие, а в очереди появилась ссылка на соответствующий объект – реализацию № 2. После запуска проекта система прочитала актуальные данные по регистратору и отправила их в ClickHouse.
Смысл показанного механизма в адресности: чтобы актуализировать движения одного регистратора, не потребовалось заново сравнивать многолетнюю историю регистра через OData. При разработке конкретного проекта всё равно нужно проверить, как обрабатываются перепроведение, исчезновение движений и замена предыдущего набора строк в целевой таблице.
Экстрактор поддерживает работу с объектами конфигурации и режимы получения данных через запросы, подготовленные источники и обработчики. В рамках проекта можно выбрать реквизиты и табличные части, получить ключи ссылочных сущностей, добавить вычисляемые поля и служебные признаки, включая временные метки выгрузки. Эти сведения нужны, например, для связывания реализации с номенклатурой и контроля свежести данных.
Приёмником в вебинаре выступал ClickHouse. В презентации также указаны PostgreSQL, Microsoft SQL Server, MySQL и сценарии с Kafka. Для табличных приёмников Экстрактор может подготовить структуру, сопоставить типы и настроить параметры записи. Операции, зависящие от бизнес-логики 1С, уместно выполнить на стороне источника; тяжёлые объединения и аналитические расчёты лучше выносить в последующие слои обработки.
В презентации приведены показатели до 10 000 строк в секунду и интервал запуска от одной секунды. Это заявленные ориентиры возможностей продукта, а не результат универсального независимого теста и не гарантия секундной доставки при любых условиях. Проверять необходимо фактическую скорость, глубину очереди, время обновления витрин и влияние на рабочие операции.
Для управления выгрузками «Денвик Аналитика» использует MCP (Model Context Protocol). В показанной архитектуре агент через MCP-сервер получает доступ к разрешённым инструментам Экстрактора: чтению метаданных, выбору объектов, созданию проектов и запуску предусмотренных операций. Для этого используются дополнительный сервисный интерфейс Экстрактора и компоненты интеграции, размещаемые в инфраструктуре заказчика.
Агент выполняет роль интерпретатора задачи и координатора действий. Сами правила извлечения, сегментация, регистрация изменений и запись в СУБД выполняются Экстрактором. MCP передаёт команды инструментам; строки данных движутся по отдельному маршруту – из 1С через Экстрактор в хранилище. Это разграничение важно и для архитектуры, и для контроля доступа.
После ручной настройки и проверки обновления регистра спикер перешёл к сценарию с агентом. Команда была сформулирована простыми словами: «Выгрузи реализации». Через инструменты MCP агент обратился к метаданным 1С, определил подходящий документ и его структуру. В диалоге уточнялось, какие атрибуты выгружать, нужна ли товарная часть, куда направить результат и как выполнять проект.
Для демонстрации выбрали реализации вместе с товарными строками. В результате в ClickHouse появились две таблицы: одна с данными шапок документов, другая с позициями товаров, количеством, суммами и ссылками на исходные реализации. По этим ссылкам таблицы можно соединить для последующей аналитики.
Это показательный результат: агент помог создать реальные настройки выгрузки и получить структурированные данные в приёмнике. Вебинар при этом не демонстрировал законченный промышленный AI-сервис, который самостоятельно гарантирует правильность любых управленческих показателей.
В качестве агента в демонстрации использовался Claude; также сообщалось о тестировании сценариев с GPT/Codex. Интеграции с локальными и открытыми моделями обсуждались как направление развития. Их готовность для конкретного развёртывания нужно проверять отдельно.
Даже корректно выгруженные данные ещё не отвечают на вопрос «Какая у нас выручка?». В 1С сведения о продажах могут отражаться в документах, регистрах и подготовленных расчётных наборах. Если дать агенту произвольный доступ ко всем таблицам, он может выбрать неверный источник, ошибиться с детализацией или посчитать одну операцию дважды.
На вебинаре предложена многослойная модель хранилища:
Для построения преобразований «Денвик Аналитика» использует DVT – визуальный low-code ETL-инструмент. В нём связи, объединения, вычисления и переходы между слоями представлены графом операций. В материалах вебинара показана архитектурная роль DVT и описана возможность управления такими процессами через MCP; подробная самостоятельная демонстрация построения витрин была обозначена как следующая тема.
Предположим, руководитель спрашивает, почему упала прибыль. Агенту нужно знать, какой показатель компания называет прибылью, за какой период его считать, какие организации и статусы документов учитывать и в какой витрине содержится согласованный результат. Названия колонок не дают всех этих ответов.
Поэтому рядом с аналитической моделью нужны определения метрик, описание источников, связи между бизнес-понятиями, правила доступа и контроль качества. Агенту лучше разрешать чтение согласованных витрин MART, а не всех таблиц STAGE и CORE. Тогда BI-отчёт и ответ на естественном языке могут опираться на один источник расчёта. Вычисления агента всё равно следует проверять, особенно если результат влияет на финансовое или операционное решение.
Прямой доступ агента к OData рабочей базы допустим только в границах утверждённых прав и сетевой политики. При использовании внешней языковой модели отдельно проверяют, какие схемы, метаданные, параметры запросов и фрагменты данных передаются поставщику. Перенос извлечения в собственное хранилище даёт больше возможностей ограничить набор доступных колонок и подготовить обезличенные витрины, однако сам по себе не гарантирует конфиденциальность.
Для корпоративной эксплуатации разрешения нужно закрепить на уровне сервисных учётных записей, СУБД, MCP-инструментов и сетевого доступа. Инструкция модели «не открывай персональные данные» не заменяет технического запрета. Если требуется локальная LLM, необходимо отдельно подтвердить совместимость конкретного агента и его поддержку нужных MCP-вызовов: на вебинаре это направление обсуждалось как развиваемое, а не как универсально готовое для любой модели.
Следует учитывать и сопровождение. Экстрактор, дополнительный веб-сервис, MCP-сервер, коннектор, хранилище и процессы DVT имеют собственные версии, настройки и журналы. При инциденте инженеру нужна возможность установить, где возникла ошибка: при регистрации события, выполнении очереди, передаче строк, трансформации или обращении AI к витрине. Расход токенов на обращения к модели также остаётся отдельной статьёй затрат.
Для первой проверки достаточно выбрать один понятный сценарий – например, выгрузку реализаций с товарными строками. Затем определить нужные поля и ключи, согласовать требования к актуальности, выполнить историческую загрузку и проверить обновление после изменения документа. Отдельно стоит проверить корректировку задним числом, перепроведение, удаление и восстановление после ошибки передачи.
После этого можно дать агенту через MCP ограниченный набор операций по настройке выгрузки и сравнить созданный им проект с ручным эталоном. Лишь когда источник и обновления проходят сверку, есть смысл добавлять CORE, MART и вопросы на естественном языке. Для небольшой разовой задачи такого контура может и не потребоваться: OData остаётся разумным инструментом, если объём и частота запросов контролируются.
1. С какими ИИ работает решение?
Ведь все данные, которые доступны агенту, передаются на иностранные серверы.
3. Какая программа используется на демонстрации?
4. Будут ли расходоваться токены? Нам нужно как-то контролировать их расход?
5. А что за программное обеспечение у вас представлено на демонстрации? Из какого набора состоит продукт?
6. Где в вашей схеме лучше хранить данные для AI (LLM) — в БД, DWH или Lakehouse?
7. Как часто нужно обновлять витрины для AI-сценариев?
8. А можно подключить локальную LLM без передачи данных во внешнее облако?
9. А что сильнее влияет на нагрузку: количество запросов или объём данных в одном запросе?
10. Можно ли ограничить AI только чтением данных? И ещё реализовать права доступа: чтобы руководитель видел одно, а сотрудник — другое?
11. Насколько сложно поддерживать такую архитектуру после внедрения?
12. Как Экстрактор понимает, какие данные изменились с момента предыдущей выгрузки?
13. Скажите, насколько безопасно подключать AI напрямую к OData рабочей базы? Не получается ли слишком сложная архитектура ради нескольких AI-запросов? Или запросов большое количество?
14. Какая минимальная периодичность обновления данных возможна на практике? И подскажите, а как в целом AI понимает структуру объектов 1С?
15. Как вы получаете данные с помощью ИИ-агентов? И какие данные?
16. А какими вы пользуетесь агентами, основными?
На вебинаре «LLM + OData + 1С: выдержит ли рабочая база AI-аналитику?», состоявшемся 1 октября 2026 года, технический директор «Денвик Аналитики» Степан Пыстин разобрал путь от прямых запросов к 1С через OData до отдельного контура данных с инкрементальной выгрузкой, ClickHouse и управлением через MCP. Разбираем техническую механику этого подхода и результаты показанной демонстрации.
Короткий ответ: OData подходит для адресных запросов и ограниченных интеграций. Когда AI-аналитике нужны большие исторические объёмы, регулярные обновления и множество пользователей, разумно вынести аналитическую нагрузку за пределы рабочей 1С. В показанной архитектуре Экстрактор 1С передаёт изменения в хранилище, DVT подготавливает данные, а AI-агент через MCP помогает управлять настройкой процессов и работать с согласованными витринами.
Почему прямой OData быстро усложняется
Первый запрос выглядит убедительно
Представим обычный сценарий: руководитель пишет агенту «Посчитай сумму продаж за октябрь». Агент находит подходящие объекты 1С, запрашивает записи реализации, получает данные, вычисляет итог и возвращает таблицу или график. Пользователю не нужно разбираться в структуре базы и писать запрос самостоятельно.
Для такого взаимодействия в 1С можно опубликовать стандартный интерфейс OData. Информационную базу размещают на веб-сервере с компонентами 1С, включают автоматический REST-сервис и указывают состав доступных объектов. Затем клиент обращается к опубликованному URL и получает машиночитаемый ответ, например JSON. С помощью параметров запроса можно выбрать поля, задать фильтр и ограничить выдачу.
Уже на этапе публикации необходимо настроить аутентификацию, HTTPS и минимальные права. Для аналитического сценария разумен доступ только на чтение. Сам факт наличия URL не делает сервис безопасным для размещения в открытом интернете.
Первая проверка обычно отвечает на вопрос «Может ли агент получить данные?». Для эксплуатации важнее следующий: «Что произойдёт, когда запросы станут регулярными, разнообразными и одновременными?»
Почему повторные вопросы создают новую нагрузку
Сегодня агент скачал реализации за месяц. Завтра его попросят сравнить год с предыдущим, затем рассчитать средний чек, а после – проверить оборачиваемость и остатки. Меняются периоды, источники и состав полей. Если на каждый запрос агент заново читает продуктивную базу, одна и та же история извлекается многократно.
У рабочей 1С в это время собственные задачи: проведение документов, расчёты, работа пользователей и регламентные операции. Частые небольшие обращения способны создавать конкуренцию за ресурсы; один тяжёлый запрос может надолго занять процессор, дисковую подсистему или соединения. Поэтому оценивать нужно одновременно частоту запросов, их стоимость, объём читаемых данных и время выполнения.
Следующий естественный шаг – развернуть отдельную СУБД, например ClickHouse, и поручить агенту подготовить скрипт периодической загрузки из OData. Аналитические запросы в таком случае выполняются уже в хранилище. Это снимает часть повторной нагрузки, но оставляет нерешённой задачу обновления: как быстро и без полного перечитывания определить, что изменилось в 1С?
Где ломается инкремент через OData
Инкрементальная загрузка предполагает, что сначала переносится исторический массив, а дальше – только новые, изменённые и удалённые данные. Для произвольного набора объектов 1С стандартный OData не предоставляет единого готового журнала всех изменений, который можно просто запросить «с момента предыдущей выгрузки». Логику обнаружения различий приходится проектировать отдельно.
Четыре стратегии для разных объектов
| Данные 1С | Возможный способ обновления через OData | Что остаётся проблемой |
|---|---|---|
| Документы | Повторно читать скользящий период по дате документа | Изменение старого документа за пределами окна останется незамеченным |
| Справочники | Сопоставлять идентификаторы и DataVersion, затем перечитывать изменённые элементы | Для поиска различий приходится опрашивать большой список ключей и версий |
| Регистры | Выявлять изменения документов-регистраторов и обновлять связанные движения | Логика зависит от регистра и связи с регистраторами; универсальной версии строки нет |
| Удаления | Периодически сверять ключи источника и приёмника | Для обнаружения отсутствующих объектов нужны дополнительные обходы и согласование правил удаления |
Для документов скользящее окно кажется практичным решением. Можно каждый день перечитывать текущий месяц и часть предыдущего. Но бухгалтерия иногда исправляет документы более ранних периодов. Если дата документа осталась прежней и вышла за границу окна, корректировка не попадёт в хранилище. Дата документа сама по себе не равнозначна времени последнего изменения.
Со справочниками ситуация другая. Допустим, в номенклатуре сотни тысяч элементов. Вместо полного чтения всех атрибутов можно запросить идентификаторы и DataVersion, сравнить их с предыдущим состоянием и догрузить изменённые карточки. Передаваемых реквизитов меньше, но саму проверку большого набора выполнять всё равно нужно.
С регистрами сложнее. Записи движений могут зависеть от проведения или изменения документа-регистратора. При обновлении регистратора иногда требуется заново получить соответствующий набор движений, включая случай, когда прежняя запись больше не должна присутствовать в аналитической таблице. Простое добавление новых строк здесь легко приводит к двойному учёту.
Отдельный вопрос – физическое удаление и пометка на удаление: эти состояния нельзя автоматически считать одинаковыми. Правила отражения обоих событий в аналитическом приёмнике должны быть определены заранее.
Почему нельзя назвать один «предел строк»
На вебинаре обсуждались условные объёмы в 100–300 тысяч записей, при которых полное обновление ещё может оказаться приемлемым, и гораздо более крупные массивы, где его стоимость резко возрастает. Это ориентиры для обсуждения архитектуры, а не установленный технический лимит OData. Реальная граница зависит от объектов, фильтров, платформы, СУБД, оборудования, конкурентной нагрузки и требований к актуальности.
Если для выгрузки требуется сегментация, контроль версий, обработка удалений, повторные попытки, преобразование типов, расписание и мониторинг, вокруг простого API постепенно возникает самостоятельная интеграционная система. AI-агент способен помочь написать её скрипты. Но сгенерированный код придётся тестировать, сопровождать и проверять на корректность после изменений конфигурации 1С. Иначе команда получает набор процедур, чьи ошибки обнаруживаются уже в управленческих отчётах.
Как Экстрактор 1С обрабатывает изменения
Первичная загрузка и очередь событий
В показанном на вебинаре решении за извлечение отвечает Экстрактор 1С – расширение, установленное в информационной базе. Он позволяет выбрать источник, поля и приёмник, организовать историческую выгрузку и последующее инкрементальное обновление. В отличие от внешнего опроса через OData, механизм регистрации изменений работает на стороне 1С, используя события объектов и информацию о регистраторах.
Сначала крупный исторический объём разбивается на сегменты – например, по датам или другим признакам, подходящим выбранному объекту. Сегменты обрабатываются отдельными порциями, при необходимости параллельно. Размер пачки и количество потоков настраиваются с учётом производительности источника и приёмника. Максимальная параллельность без контроля может сама создать избыточную нагрузку на 1С.
После первичной загрузки Экстрактор регистрирует события изменения и формирует очередь заданий. В очереди фиксируется, какой объект или связанный набор данных необходимо обновить; для каждой операции не требуется хранить копию всей исторической таблицы. По расписанию обработчик получает актуальное состояние и отправляет его в приёмник.
Такой подход уменьшает число повторных чтений неизменившейся истории. При этом производительность и задержка остаются эксплуатационными характеристиками, которые необходимо измерять в конкретной информационной базе.
Что происходит с регистрами
В демонстрации использовался регистр выручки и себестоимости, движения которого связаны с документами реализации. Спикер изменил документ реализации товаров и услуг. Экстрактор зарегистрировал событие, а в очереди появилась ссылка на соответствующий объект – реализацию № 2. После запуска проекта система прочитала актуальные данные по регистратору и отправила их в ClickHouse.
Смысл показанного механизма в адресности: чтобы актуализировать движения одного регистратора, не потребовалось заново сравнивать многолетнюю историю регистра через OData. При разработке конкретного проекта всё равно нужно проверить, как обрабатываются перепроведение, исчезновение движений и замена предыдущего набора строк в целевой таблице.
Какие данные можно подготовить
Экстрактор поддерживает работу с объектами конфигурации и режимы получения данных через запросы, подготовленные источники и обработчики. В рамках проекта можно выбрать реквизиты и табличные части, получить ключи ссылочных сущностей, добавить вычисляемые поля и служебные признаки, включая временные метки выгрузки. Эти сведения нужны, например, для связывания реализации с номенклатурой и контроля свежести данных.
Приёмником в вебинаре выступал ClickHouse. В презентации также указаны PostgreSQL, Microsoft SQL Server, MySQL и сценарии с Kafka. Для табличных приёмников Экстрактор может подготовить структуру, сопоставить типы и настроить параметры записи. Операции, зависящие от бизнес-логики 1С, уместно выполнить на стороне источника; тяжёлые объединения и аналитические расчёты лучше выносить в последующие слои обработки.
В презентации приведены показатели до 10 000 строк в секунду и интервал запуска от одной секунды. Это заявленные ориентиры возможностей продукта, а не результат универсального независимого теста и не гарантия секундной доставки при любых условиях. Проверять необходимо фактическую скорость, глубину очереди, время обновления витрин и влияние на рабочие операции.
Что AI-агент делает через MCP
У модели появляется определённый набор инструментов
Для управления выгрузками «Денвик Аналитика» использует MCP (Model Context Protocol). В показанной архитектуре агент через MCP-сервер получает доступ к разрешённым инструментам Экстрактора: чтению метаданных, выбору объектов, созданию проектов и запуску предусмотренных операций. Для этого используются дополнительный сервисный интерфейс Экстрактора и компоненты интеграции, размещаемые в инфраструктуре заказчика.
Агент выполняет роль интерпретатора задачи и координатора действий. Сами правила извлечения, сегментация, регистрация изменений и запись в СУБД выполняются Экстрактором. MCP передаёт команды инструментам; строки данных движутся по отдельному маршруту – из 1С через Экстрактор в хранилище. Это разграничение важно и для архитектуры, и для контроля доступа.
Что было показано на вебинаре
После ручной настройки и проверки обновления регистра спикер перешёл к сценарию с агентом. Команда была сформулирована простыми словами: «Выгрузи реализации». Через инструменты MCP агент обратился к метаданным 1С, определил подходящий документ и его структуру. В диалоге уточнялось, какие атрибуты выгружать, нужна ли товарная часть, куда направить результат и как выполнять проект.
Для демонстрации выбрали реализации вместе с товарными строками. В результате в ClickHouse появились две таблицы: одна с данными шапок документов, другая с позициями товаров, количеством, суммами и ссылками на исходные реализации. По этим ссылкам таблицы можно соединить для последующей аналитики.
Это показательный результат: агент помог создать реальные настройки выгрузки и получить структурированные данные в приёмнике. Вебинар при этом не демонстрировал законченный промышленный AI-сервис, который самостоятельно гарантирует правильность любых управленческих показателей.
В качестве агента в демонстрации использовался Claude; также сообщалось о тестировании сценариев с GPT/Codex. Интеграции с локальными и открытыми моделями обсуждались как направление развития. Их готовность для конкретного развёртывания нужно проверять отдельно.
Как готовятся данные для AI
От сырых таблиц к проверяемым показателям
Даже корректно выгруженные данные ещё не отвечают на вопрос «Какая у нас выручка?». В 1С сведения о продажах могут отражаться в документах, регистрах и подготовленных расчётных наборах. Если дать агенту произвольный доступ ко всем таблицам, он может выбрать неверный источник, ошибиться с детализацией или посчитать одну операцию дважды.
На вебинаре предложена многослойная модель хранилища:
- STAGE – извлечённые из 1С данные с минимальной обработкой. Здесь сохраняются исходные идентификаторы и признаки, необходимые для проверки полноты и последующих преобразований.
- CORE – согласованные сущности: приведённые типы, связи объектов, правила обработки ссылок и очищенные наборы. Здесь техническая структура приближается к общей модели предметной области.
- MART – витрины для конкретных аналитических задач. В них закрепляют определения показателей, зерно расчёта, нужные агрегаты и допустимый состав данных для потребителей.
Для построения преобразований «Денвик Аналитика» использует DVT – визуальный low-code ETL-инструмент. В нём связи, объединения, вычисления и переходы между слоями представлены графом операций. В материалах вебинара показана архитектурная роль DVT и описана возможность управления такими процессами через MCP; подробная самостоятельная демонстрация построения витрин была обозначена как следующая тема.
Почему бизнес-глоссарий важнее красивого ответа
Предположим, руководитель спрашивает, почему упала прибыль. Агенту нужно знать, какой показатель компания называет прибылью, за какой период его считать, какие организации и статусы документов учитывать и в какой витрине содержится согласованный результат. Названия колонок не дают всех этих ответов.
Поэтому рядом с аналитической моделью нужны определения метрик, описание источников, связи между бизнес-понятиями, правила доступа и контроль качества. Агенту лучше разрешать чтение согласованных витрин MART, а не всех таблиц STAGE и CORE. Тогда BI-отчёт и ответ на естественном языке могут опираться на один источник расчёта. Вычисления агента всё равно следует проверять, особенно если результат влияет на финансовое или операционное решение.
Безопасность, ограничения и практический запуск
Прямой доступ агента к OData рабочей базы допустим только в границах утверждённых прав и сетевой политики. При использовании внешней языковой модели отдельно проверяют, какие схемы, метаданные, параметры запросов и фрагменты данных передаются поставщику. Перенос извлечения в собственное хранилище даёт больше возможностей ограничить набор доступных колонок и подготовить обезличенные витрины, однако сам по себе не гарантирует конфиденциальность.
Для корпоративной эксплуатации разрешения нужно закрепить на уровне сервисных учётных записей, СУБД, MCP-инструментов и сетевого доступа. Инструкция модели «не открывай персональные данные» не заменяет технического запрета. Если требуется локальная LLM, необходимо отдельно подтвердить совместимость конкретного агента и его поддержку нужных MCP-вызовов: на вебинаре это направление обсуждалось как развиваемое, а не как универсально готовое для любой модели.
Следует учитывать и сопровождение. Экстрактор, дополнительный веб-сервис, MCP-сервер, коннектор, хранилище и процессы DVT имеют собственные версии, настройки и журналы. При инциденте инженеру нужна возможность установить, где возникла ошибка: при регистрации события, выполнении очереди, передаче строк, трансформации или обращении AI к витрине. Расход токенов на обращения к модели также остаётся отдельной статьёй затрат.
С чего начать без большого проекта
Для первой проверки достаточно выбрать один понятный сценарий – например, выгрузку реализаций с товарными строками. Затем определить нужные поля и ключи, согласовать требования к актуальности, выполнить историческую загрузку и проверить обновление после изменения документа. Отдельно стоит проверить корректировку задним числом, перепроведение, удаление и восстановление после ошибки передачи.
После этого можно дать агенту через MCP ограниченный набор операций по настройке выгрузки и сравнить созданный им проект с ручным эталоном. Лишь когда источник и обновления проходят сверку, есть смысл добавлять CORE, MART и вопросы на естественном языке. Для небольшой разовой задачи такого контура может и не потребоваться: OData остаётся разумным инструментом, если объём и частота запросов контролируются.
Вывод. Устойчивость AI-аналитики на данных 1С определяется качеством архитектуры вокруг модели. OData позволяет быстро проверить идею. Для регулярных запросов, больших объёмов и управляемого обновления данных необходим механизм извлечения изменений, внешний аналитический контур и согласованные показатели. В продемонстрированном подходе эту основу обеспечивают Экстрактор 1С, хранилище и DVT, а MCP предоставляет AI-агенту инструменты для работы с процессами без постоянного прямого чтения продуктивной базы.
Видео с вебинара
Ответы на вопросы с вебинара:
1. С какими ИИ работает решение?
На момент вебинара решение работает с Claude и GPT, включая Codex. Поддержку отечественных и open-source-моделей планируется добавить до конца 2026 года.2. Как обеспечивается приватность?
Ведь все данные, которые доступны агенту, передаются на иностранные серверы.
Для защиты данных предлагается использовать отдельные слои хранилища. Персональные и конфиденциальные данные остаются во внутреннем слое, а агенту предоставляется доступ только к подготовленным витринам с агрегированными и обезличенными данными. Правила взаимодействия с хранилищем задаются через инструкции для агента. Альтернативный вариант — использование локальных моделей или российских AI-сервисов, например YandexGPT.
3. Какая программа используется на демонстрации?
В записи спикер не повторил название непосредственно в ответ на этот вопрос. В ходе демонстрации использовались Экстрактор 1С компании «Денвик Аналитика» и AI-агент Claude, взаимодействующий с Экстрактором через MCP.
4. Будут ли расходоваться токены? Нам нужно как-то контролировать их расход?
Да, при обращении к AI-агенту токены расходуются. Использование MCP позволяет сократить их потребление, поскольку инструкции по взаимодействию с Экстрактором уже описаны на стороне MCP-сервера. Спикер привёл условный пример: без MCP агент может потратить миллион токенов, а с MCP — около тысячи на аналогичную задачу. Это иллюстрация принципа экономии, а не результат измерения.
5. А что за программное обеспечение у вас представлено на демонстрации? Из какого набора состоит продукт?
В показанной интеграции используются Экстрактор 1С, дополнительный веб-сервис на стороне 1С, MCP-сервер, MCP-коннектор и AI-агент Claude. Данные выгружаются в ClickHouse. В демонстрации также использовался инструмент для просмотра таблиц базы данных.
6. Где в вашей схеме лучше хранить данные для AI (LLM) — в БД, DWH или Lakehouse?
DWH отличается от обычной базы данных наличием дополнительных инструментов: бизнес-глоссария, каталога данных, прослеживаемости показателей и версионирования. Для корректной работы AI-агенту необходимо предоставлять эти описания, поскольку одних таблиц и комментариев к полям недостаточно для понимания бизнес-смысла данных.
7. Как часто нужно обновлять витрины для AI-сценариев?
Частота обновления зависит от необходимой актуальности данных. Если для аналитики достаточно данных за предыдущий день, можно обновлять витрины ежедневно. Если бизнес требует информации в реальном времени или с небольшой задержкой, обновления должны выполняться чаще.
8. А можно подключить локальную LLM без передачи данных во внешнее облако?
Да, возможность подключения локальных моделей предусмотрена. На момент вебинара работа была реализована и протестирована с Claude и GPT/Codex. Поддержка локальных и open-source-моделей пока в активной разработке.
9. А что сильнее влияет на нагрузку: количество запросов или объём данных в одном запросе?
Оба фактора создают нагрузку, но по-разному. Большое количество запросов может вызывать конкуренцию за ресурсы и проблемы с блокировками. Один запрос на получение, например, 10 миллионов записей тоже способен выполняться очень долго. Поэтому, сравнивать эти факторы напрямую не совсем корректно. Оптимизировать необходимо оба.
10. Можно ли ограничить AI только чтением данных? И ещё реализовать права доступа: чтобы руководитель видел одно, а сотрудник — другое?
Да. Права можно разграничить на уровне пользователя базы данных или хранилища, ограничив доступ к определённым таблицам. Также разграничение можно реализовать на уровне MCP-сервера, который будет контролировать доступ пользователей в соответствии с ролевой моделью.
11. Насколько сложно поддерживать такую архитектуру после внедрения?
Помимо основного расширения Экстрактора необходимо поддерживать дополнительный веб-сервис и MCP-коннектор, следить за актуальностью их версий и устанавливать обновления. Компания планирует реализовать инструменты развёртывания и проверки версий компонентов, чтобы обеспечить их согласованную работу.
12. Как Экстрактор понимает, какие данные изменились с момента предыдущей выгрузки?
Экстрактор использует подписки на события внутри 1С и отслеживает создание, изменение и удаление объектов. При изменении объекта информация о нём регистрируется в очереди выгрузки. Затем Экстрактор выгружает соответствующие записи в хранилище. Таким образом, после первоначальной загрузки не требуется каждый раз повторно выгружать все данные.
13. Скажите, насколько безопасно подключать AI напрямую к OData рабочей базы? Не получается ли слишком сложная архитектура ради нескольких AI-запросов? Или запросов большое количество?
Мы не считаем прямое подключение AI к OData рабочей базы достаточно безопасным подходом для регулярной аналитики. При каждом запросе агент обращается непосредственно к продуктивной системе и создаёт дополнительную нагрузку. Кроме того, возникают вопросы разграничения доступа к конфиденциальным данным. Использование промежуточного хранилища позволяет отделить аналитические запросы от рабочей базы и контролировать доступ к данным. Относительно количества запросов отметим, что после начала использования AI-аналитики у пользователей обычно появляется всё больше вопросов к данным.
14. Какая минимальная периодичность обновления данных возможна на практике? И подскажите, а как в целом AI понимает структуру объектов 1С?
Минимальный интервал запуска задания на выгрузку, названный спикером, — одна секунда. Экстрактор отслеживает изменения, поэтому при небольшом количестве изменившихся записей данные могут выгружаться практически мгновенно. Структуру объектов 1С агент получает через метаданные конфигурации, которые доступны Экстрактору. Он видит документы, справочники, регистры и описания полей. Для понимания назначения объектов типовых конфигураций используется документация. Если компания использует собственные объекты или доработки с особой бизнес-логикой, агенту потребуется предоставить соответствующую документацию.
15. Как вы получаете данные с помощью ИИ-агентов? И какие данные?
Данные из 1С получает Экстрактор 1С, после чего они загружаются в промежуточное хранилище. AI-агент может использовать данные этого хранилища для анализа. Во время демонстрации через AI-агента создавались проекты выгрузки документов «Реализация товаров и услуг». В результате были созданы две таблицы: одна с данными шапки документа, вторая — с товарной частью, включая номенклатуру, количество, сумму и ссылку на реализацию. Для корректной аналитики агенту также необходимы инструкции о том, какие таблицы использовать для определённых показателей.
16. А какими вы пользуетесь агентами, основными?
Часть сотрудников компании использует активно Claude, который больше понравился в работе. Другие специалисты компании используют Codex на базе GPT. Оба инструмента тестировались для работы с Экстрактором 1С через MCP.
