Метавизия для 1С: как обогнали чанки и создали три источника фактов для ИИ-агента

# Как мы научили ИИ-агента понимать чужую кодовую базу: вместо чанков — три источника фактов

В разработке систем искусственного интеллекта, особенно при работе с корпоративным софтом вроде платформ 1С, возникает специфический вызов:如何让 агента не просто находить текст, а понимать логику и контекст кода. Команда разработчиков MetaVision for 1C, создающих программы для статического анализа конфигураций с помощью ИИ-агентов, столкнулась с проблемой, знакомой многим энтузиастам нейросетей. На реальных проектах традиционная схема RAG (Retrieval-Augmented Generation) — разбивка текста на куски (чанки), их векторизация и поиск по эмбеддингам — показала себя недостаточно эффективной.

Агент, обученный на такой базе данных, часто уверенно заявлял о том, что определенного кода в системе нет, хотя он там явно присутствовал. Это классический случай, когда поиск по векторам проваливается из-за потери контекста при нарезке текста. В этой статье мы расскажем, почему стандартный подход не сработал на коде и как инженеры MetaVision решили эту задачу, построив архитектуру с тремя источниками фактов.

Почему чанки не работают на коде

Проблема использования чанков (чанкования) заключается в том, что код — это не просто текст. Это логическая структура, где значимость строки или абзаца часто зависит от того, что находится выше или ниже, и как эти элементы связаны с остальной частью программы.

При обычной нарезке текста агентам часто приходится работать с неполными контекстами. Если в коде реализована сложная логика распределения ресурсов или обработка исключений, разбивка по символам или словам может порвать цепочку рассуждений. Агент видит фрагмент кода без его функционального назначения и делает ошибочный вывод о его наличии или отсутствии.

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

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

Архитектура трех источников фактов

Чтобы решить проблему потери контекста, команда MetaVision for 1C отказалась от простой зависимости от одного типа поиска и создала гибридную систему, основанную на трех взаимодополняющих источниках фактов, хранящихся в единой базе данных SQLite.

Эта архитектура включает в себя:

1. SQL-индекс: Используется для точного поиска по конкретным ключевым словам, именам процедур, функциям и атрибутам метаданных. Это обеспечивает гарантированное получение информации о существовании объекта в системе. 2. Полнотекстовый поиск FTS5: Технология Full-Text Search версии 5 от SQLite позволяет искать по содержимому кода с учетом морфологии и синонимов, что важно для поиска описаний и комментариев, которые могут быть написаны разными словами. 3. Векторное хранилище: Сохраняет эмбеддинги фрагментов кода для поиска по смыслу, когда точное совпадение по ключевым словам невозможно, но контекст похож.

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

Граф вызовов и скрытые связи

Вторым ключевым элементом новой архитектуры стал граф вызовов. Код — это не изолированные функции, а сеть взаимосвязанных процедур. Один вызов может влиять на поведение всей системы, и понимание этих связей критически важно для корректного анализа.

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

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

Итоги и перспективы

Переход от простой схемы RAG на основе чанков к гибридной модели с тремя источниками фактами и графом вызовов стал прорывом для анализа кода 1С. Теперь ИИ-агент способен давать более точные и обоснованные ответы, не утверждая о небытии того, что есть.

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

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