Первого сентября состоялся вебинар, посвящённый обучению ИИ-агента чтению документации к внутреннему Java-фреймворку. Демонстрация была построена вокруг кода: нишевый фреймворк, библиотека без исходников, файл AGENTS.md рядом с проектом. Однако первый же вопрос из зала сместил фокус с программирования на юридически значимые документы. Системный аналитик описал задачу: создать систему, которая отвечает на запросы по корпусу приказов по информационной безопасности, ГОСТов и спецификаций, причём ответ должен содержать ссылку на конкретный пункт. Структуру документа трогать нельзя, поскольку он имеет юридическую силу. В чате развернулась дискуссия о том, как обеспечить точность и проверяемость таких ответов.

Ключевое отличие нормативки от кода — отсутствие внешнего арбитра, подобного компилятору. В программировании, если агент выдумает несуществующий метод, сборка завершится ошибкой, и это будет замечено. Конечно, не все ошибки ловятся на этапе компиляции: на том же вебинаре у одного из участников сборка прошла успешно, но приложение упало в рантайме. Тем не менее компилятор выступает объективным судьёй. В случае с нормативными документами такого арбитра нет: пересказ несуществующего пункта выглядит так же убедительно, как и правильный ответ. Поэтому возникает задача построить искусственного арбитра и организовать поиск, ориентированный на него. Пример с редакциями приказов показывает, насколько сложной может быть цепочка изменений. Государственные информационные системы долгое время защищались по приказу ФСТЭК № 17, но с 1 марта 2026 года его заменил приказ ФСТЭК России от 11.04.2025 № 117, зарегистрированный Минюстом 16.06.2025 под № 82619. Этот документ отменил пять позиций, включая приказы № 17, № 27, № 106, № 61 и пункт 1 изменений из приказа № 159. Аттестаты, выданные до 1 марта 2026 года, считаются действительными согласно пункту 3. С 1 сентября 2026 года требования будут действовать в редакции приказа № 137 от 08.05.2026. Эта цепочка редакций не заканчивается, и за ней должен следить специальный индекс. Кроме того, в обзорах часто встречаются оговорки, отсутствующие в оригинальных текстах, например, что аттестат действует «до истечения срока» и «при неизменности конфигурации». Настоящее ограничение содержится в другом документе — информационном сообщении ФСТЭК от 12.03.2026 № 240/22/1492, которое требует дополнительных аттестационных испытаний после модернизации системы. Модель, обученная на данных до 2025 года, скорее всего, ответит «по приказу № 17», что фактически правильно, но документ уже устарел.

В ходе обсуждения были предложены три подхода к решению проблемы. Первый вариант, предложенный ведущим, заключается в использовании статичной документации в виде файлов и поиска с помощью grep: агент ищет и читает сам, а MCP для статичного корпуса считается лишней шестерёнкой, добавляющей лишний вызов в цепочке. Слабой модели корпус стоит заранее разложить в индекс под её окно. Второй участник в чате возразил, что grep — прошлый век, и предложил локальный поисковый индекс, аналогичный поиску в Windows, передаваемый агенту через MCP. Он уточнил, что в RAG первые этапы конвейера возвращают документы, а пересказывает только последний, генеративный этап; если его убрать, оригиналы останутся нетронутыми. Третий подход, от аналитика из зала, указывает на тяжеловесность RAG: требуется база, векторное хранилище, подготовка данных. Главное — при подготовке модель может переиначить пункт, и оригинал потеряется. Он сравнил это с неопределённым поведением в C++, где под капотом что-то оптимизировали, а что именно — неизвестно. Ему интересен иерархический индекс с навигацией по дереву и ссылками на пункты, хотя индексация требует прохода по всему корпусу. Участники пришли к выводу, что генеративный последний шаг придётся отключать или закрывать проверкой цитат, а MCP на качество поиска не влияет, это лишь транспорт. Остальные вопросы остались открытыми: дешевле ли сохранить оригинал, чем восстанавливать его из пересказа, и насколько сложным должен быть поиск, если читать всё равно будет модель.

При подготовке статьи были изучены готовые решения. Правовые базы с ИИ, такие как КонсультантПлюс с ИИ-помощником и экспериментальной «Проверкой ссылок» (с июля 2026 года), проверяют, действуют ли акты, на которые сослалась нейросеть, но сверяют ли они цитату с текстом пункта, из описания неясно. У Гаранта есть ассистент ИСКРА и API Гарант Коннект, на базе которого работает Нейроюрист от Яндекса. Кодекс запустил КодексНейро, отвечающий по ГОСТам и другой НТД со ссылками на пункты. Сильная сторона всех этих решений — актуальные редакции, которые ведутся десятилетиями, и повторять эту работу в своём контуре не имеет смысла: актуальный текст проще забирать через API. Нейроюрист также принимает свои документы и в бизнес-тарифах заявляет «работу в контуре компании». Однако ответ везде пишет модель, что соответствует варианту D, тогда как аналитику нужен оригинал. Зарубежные Lexis+ AI и Westlaw AI тоже построены на RAG с генерацией и продавались как «hallucination-free», но в 2024 году Стэнфорд проверил их и обнаружил галлюцинации в 17–33% ответов. Существуют и MCP-серверы по праву РФ: garant-mcp отдаёт дословный текст статьи и редакцию на дату, но ходит в Гарант через сессию браузера с вашей подпиской; russian-law-mcp держит федеральные законы в локальной SQLite с полнотекстовым поиском. Оба распространяются под Apache 2.0. Таким образом, поиск, выдачу оригинала и проверку цитат придётся собирать в своём контуре, и вопрос в том, как обойтись минимумом деталей.

Далее были рассмотрены пять подходов к организации поиска. Подход A — файлы и grep: корпус лежит в репозитории в markdown, агент ищет с помощью ripgrep и читает найденное. Подготовка включает сохранение нумерации пунктов при конвертации, агент получает оригинал без промежуточных шагов. Однако возникает проблема морфологии: строка «оператора персональных данных» не содержит строку «оператор персональных данных». Частично это лечится стеммингом в регулярном выражении, например, rg -i 'оператор\w*\s+персональн\w*' corpus/. Такой шаблон найдёт «ОПЕРАТОРА персональных» и «операторам персональных», но пропустит «персональных данных оператором» из-за другого порядка слов. Синонимы и перефразы не будут найдены вовсе. Сильная модель догадается урезать окончания и перебирать варианты, слабая — нет. Ответ зависит от движка: в трёх локалях были проведены прогоны. Необходимы две функции: приведение кириллицы к нижнему регистру и её учёт как \w. У ripgrep и ugrep 7.8.4 есть обе в любой локали, GNU grep умеет обе только в UTF-8-локали, а grep -P не считает кириллицу за \w без (*UCP). Две версии ugrep разошлись: 3.11.2 из Debian 12 не приводит к нижнему регистру. Обратный порядок слов не нашёлся нигде. Grep годится как точка отсчёта: подготовка ничего не стоит, но чтение требует токенов, так как найденные файлы агент читает целиком. Подход B — полнотекстовый индекс с морфологией, где каждый пункт представлен строкой в индексе с реквизитами, а поиск ранжирует пункты по совпадению. Этот подход продолжает развиваться, но уже ясно, что выбор между простотой и точностью остаётся открытым.

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