Все статьи

8 сентября 2026 г.

Почему ИИ-агенты галлюцинируют в конфигурациях 1С и как это исправить?

Почему ИИ-агенты галлюцинируют на кодовой базе 1С

Когда разработчик просит Claude Code, Cursor или Windsurf доработать документ «Приобретение товаров и услуг» в типовой конфигурации, агент не обращается к официальной документации. Он пытается понять проект из файлового контекста. Но полная выгрузка конфигурации ERP, УТ, ЗУП или КА — это гигабайты XML-метаданных и сотни тысяч строк кода на BSL.

В 200k-контекстное окно LLM помещается лишь небольшая часть такой базы. Модель начинает отбрасывать файлы, упрощать структуру, а недостающие данные «додумывает». Именно так рождаются галлюцинации — уверенно сгенерированные методы, документы и модули, которых нет в реальной конфигурации.

// Типичная «фантазия» ИИ-агента без доступа к точным метаданным:
Справочники.Номенклатура.НайтиПоРеквизиту("Артикул", "A-001");

В реальной типовой конфигурации такого метода может не быть. Модель собрала его из шаблонов платформы, а не из кода проекта. Результат — неработающий код и потерянное время.

Три корневые причины галлюцинаций

1. XML-метаданные не являются структурой, понятной LLM

Конфигурация 1С — это деревья метаданных, экспортируемые в XML. Внутри XML-файлов нет ответа на вопрос «кто вызывает этот общий модуль и какие методы реально существуют». ИИ-агент видит разрозненные теги, длинные строки свойств и табличных частей.

Модель не способна по XML-файлу понять связность кода. Поэтому она реконструирует архитектуру «по вероятности»: берёт имена из соседних файлов, из неполного кода, из общих знаний о платформе и типовых решениях, которые встречались в тренировочных данных. Для закрытых конфигураций 1С таких данных в обучении практически нет — отсюда уверенные ошибки.

2. Переполнение контекста и «потеря середины»

Даже если частично загрузить в контекст модуль объекта документа, он легко занимает 15–20 тыс. строк. Модуль содержит десятки процедур, а целевая функция похоронена в середине. Исследования LLM показывают: при переполнении контекста модель резко теряет точность на середине входной последовательности.

Из-за этого агент «забывает», что нужная переменная уже объявлена в начале модуля, или начинает выдумывать обработчики событий, которые не подписаны в конфигурации.

// Агент с переполненным контекстом часто пишет так:
Документы.ПоступлениеТоваровУслуг.СоздатьДокумент().Записать();

Проблема в том, что документ в конфигурации называется иначе, а метод СоздатьДокумент() отсутствует. Модель заменяет неизвестное правдоподобной конструкцией — классическая галлюцинация.

3. Отсутствие графа вызовов

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

  • кто вызывает ОбработкаПроведения
  • к каким общим модулям обращается эта процедура
  • какие подписки на события срабатывают при проведении документа

Без такого графа ИИ-агент использует эвристику. Он ищет вхождение имени процедуры по всем файлам проекта, но теряет контекст из-за большого объёма совпадений. В итоге агент делает ложные выводы: «если процедура называется так же, значит, она от несуществующего интерфейса».

Почему просто «скормить файлы» не работает

Некоторые команды пытаются использовать RAG-подход: разбить XML и модули BSL на чанки, сложить в векторную базу, а затем подставлять в промпт «похожие» куски. Но для архитектуры 1С RAG на тексте неэффективен.

Конфигурация — это связный граф объектов, а не плоская текстовая документация. Разбиение на чанки разрушает цепочку вызовов. ИИ получает обрывки с одинаковыми названиями процедур в разных модулях и не может понять, какой из них относится к задаче.

Нужен инструмент, который понимает семантику конфигурации: метаданные, подписки, права, общие модули, запросы и точки вызова.

Что такое Grafon и как он решает проблему

Grafon — локальный инструмент и MCP-сервер для конфигураций 1С. Он анализирует всю конфигурацию и строит граф зависимостей:

  • объекты метаданных
  • процедуры и функции модулей
  • подписки на события
  • вызовы общих модулей
  • структуру запросов к базам данных

ИИ-агент через протокол MCP обращается к Grafon и получает только точный срез связанных файлов и сигнатур. В контекст не попадает «весь общий модуль целиком» — только необходимые функции и их вызовы.

Конфигурация 1С (.dt / XML)
        ↓
     Grafon — парсинг метаданных и BSL
        ↓
    граф зависимостей
        ↓
    MCP-сервер (локальный)
        ↓
Claude Code / Cursor / Windsurf

Пример MCP-запроса к Grafon:

grafon.get_subgraph
{
  "node": "Документ.ПриобретениеТоваровУслуг.МодульОбъекта.ОбработкаПроведения",
  "depth": 2,
  "include": ["callers", "callees", "subscriptions"]
}

В ответ возвращаются не сырые XML-файлы, а структурированные данные: точные сигнатуры, списки вызываемых процедур, обработчики подписок. Агент больше не гадает, существует ли метод. Он работает с верифицированной информацией.

Сравнение подходов: без Графона и с Графоном

Расчётные показатели для сценария «добавить реквизит в документ и реализовать проведение на основании счёта»:

| Параметр | Без Графона (полная загрузка файлов) | С Графоном (MCP-срез) |
|---|---|---|
| Загружено в контекст | 500–700 тыс. токенов | 30–50 тыс. токенов |
| Время выполнения задачи | 8–15 минут, частая деградация | 1–3 минуты |
| Переполнение контекста | критическое | отсутствует |
| Точность сигнатур | 40–60%, угадывание | 95%+, по метаданным |
| Количество галлюцинаций | 3–6 за задачу | почти нулевое |

За счёт графа зависимостей Grafon сокращает потребление токенов до 10 раз. Для команд, которые используют ИИ-ассистентов на коммерческих тарифах или через API, это прямое снижение бюджета.

Практический сценарий для тимлида

Допустим, разработчик работает с документом ПриобретениеТоваровУслуг и хочет добавить логику в проведение.

Без Графона агент пытается найти все упоминания документа по всей конфигурации. Контекст быстро переполняется подписками на события, печатными формами, общими модулями, которые не относятся к делу.

С Графоном запрос выглядит так:

grafon.get_callers
{
  "function": "ОбработкаПроведения",
  "object": "Документ.ПриобретениеТоваровУслуг"
}

Агент получает цепочку: подписки на событие «Перед записью» → процедура из общего модуля → вызов менеджера документа. Дальше он изменяет только нужный участок кода.

// BSL-код, который агент формирует после получения точного среза:
Процедура ОбработкаПроведения(Отказ, РежимПроведения)


// Графон дал точное имя общего модуля и метода:
    ОбщегоНазначения.СообщитьПользователю(
        "Проведение выполняется в режиме: " + Строка(РежимПроведения));
    // ... логика разработчика



КонецПроцедуры

Когда ИИ-агент перестаёт галлюцинировать

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

  • дать агенту точные имена функций, процедур, объектов метаданных
  • ограничить контекст минимально необходимым набором кода

Grafon решает обе задачи. Он физически не передаёт агенту полную конфигурацию. Вместо этого поставляются компактные графовые срезы, которые точно описывают архитектуру в точке изменения. Модель больше не вынуждена «угадывать» API. Она использует те же сигнатуры, которые видят разработчик и компилятор платформы.

Вывод для архитекторов и команд разработки

Галлюцинации ИИ-агентов в конфигурациях 1С — это не недостаток конкретной модели, а следствие неверного формата передачи знаний. Гигабайты XML и сотни тысяч строк BSL не помещаются в контекст, а закрытые типовые конфигурации плохо представлены в обучающих данных LLM.

Чтобы сделать ИИ-ассистента безопасным для производства, нужен архитектурный слой — локальный граф зависимостей, доступный через MCP. Grafon даёт агенту только точные срезы метаданных и кода, исключает переполнение контекста, сокращает расходы на токены и устраняет причину системных галлюцинаций.

Попробовать Графон бесплатно