73% автоматизированных консультаций в государственном секторе превращаются в жалобы граждан, если бот не подкрепляет свой ответ прямой ссылкой на нормативный акт. Вы думаете, что разгружаете первую линию поддержки, а на самом деле генерируете DDoS-атаку разъярённых людей на живых операторов. ИИ-ассистент в госуслугах и МФЦ: RAG по регламентам, который отвечает по закону, а не выдумывает — это не модный пресс-релиз, это единственный способ не получить по шапке за массовую дезинформацию населения.
Хотите гарантированно завалить такой проект? Возьмите популярную облачную LLM из коробки, налейте туда системный промпт в духе «ты вежливый помощник госуслуг» и пустите в продакшен. Граждане приходят с простыми, но критичными жизненными ситуациями: пособие на ребенка, регистрация пристройки, восстановление утерянных документов. Они не знают номеров регламентов. Они формулируют запрос на эмоциях и бытовом уровне. Классический поиск по порталу здесь капитулирует сразу. Операторы первой линии перегружены и выгорают, работая живыми словарями-переводчиками, а из-за спешки выдают разнобой в ответах. Кажется, нейросеть всё исправит. Она и исправит. Она сгенерирует потрясающе эмпатичный текст, в котором очень уверенно посоветует бабушке принести для оформления субсидии справку, отменённую указом три года назад.
В реальном мире госсектора галлюцинация системы — это не забавный скриншот для соцсетей, а инцидент с юридическими последствиями. ИИ-ассистент не имеет права принимать решения. Честный и неизбежный трейд-офф здесь заключается в том, что задача алгоритма — исключительно навигация и предоставление справочной информации.
Именно поэтому любая свободная генерация ответов категорически запрещена. Единственная выживающая под такой нагрузкой архитектура — это жесткий пайплайн Retrieval-Augmented Generation, где областью поиска выступает строго ограниченный, версионируемый реестр нормативно-правовых актов. Бот не синтезирует знания из весов гигантской модели. Он работает как интеллектуальный маршрутизатор: понимает интенцию, ищет точное семантическое совпадение в векторной базе утвержденных документов, извлекает конкретный абзац и переводит канцелярский язык на человеческий. При этом алгоритм принудительно пришивает к ответу верифицируемую ссылку на первоисточник.
Я видел достаточно «умных» систем, которых муниципалитеты со скандалом сносили через неделю после пилота, прежде чем мы в Morana Labs окончательно закрепили архитектуру с нулевой толерантностью к галлюцинациям как единственный отраслевой стандарт.
Отдельный гвоздь в гроб проекта — попытка сэкономить и использовать внешние API по подписке. Речь идет об обработке обращений граждан, потенциально содержащих персональные данные. Требования информационной безопасности и инфраструктурного суверенитета здесь не обсуждаются. Никаких внешних серверов. Развертывание только on-prem, глубоко внутри защищенного контура заказчика. Вы тащите тяжелые открытые модели, эмбеддеры и векторные базы на железо клиента. Ваша реальная инженерная проблема — как уложить весь этот тяжеловесный инференс в доступные серверные мощности без деградации времени ответа в часы пиковых нагрузок.
Считаете, что пользователь разозлится, если ассистент прямо ответит «я не нашел информации»? Да. Но вежливый отказ при низкой уверенности алгоритма обходится государству в тысячу раз дешевле, чем выдуманная юридическая консультация. Если шаг поиска возвращает документы со скором релевантности ниже заданного жесткого порога, генерация ответа блокируется намертво. Система честно и быстро переводит диалог на живого сотрудника.
Очередной способ всё сломать — закинуть в пайплайн обработки сырые PDF-файлы постановлений или криво отсканированные муниципальные акты 2012 года. Вы получите мусор от OCR, разорванные таблицы и оторванные сноски. В законах постоянно встречаются отсылки вида «согласно подпункту „в“ пункта 4 статьи 12 настоящего положения». Если нарезать текст на слепые чанки по 500 токенов, алгоритм мгновенно потеряет контекст. Каждый фрагмент текста в индексе обязан нести в метаданных полную иерархическую структуру документа. LLM должна понимать, из какого именно абзаца, какой главы и какого федерального закона она сейчас формирует ответ, иначе перекрестные ссылки сломают логику.
Выкатывать подобную систему без сурового пайплайна непрерывной оценки — самоубийство. Забудьте про абстрактные опросы об «удовлетворенности». Вы смотрите на жесткие, измеримые цифры. Первая: доля обращений, закрытых без участия оператора. Вторая: точность извлечения фактов по golden set — эталонному, постоянно растущему набору из десятков тысяч пар «вопрос-ответ», собранному и выверенному старшими методологами МФЦ. Третья, самая важная: доля ответов с корректной ссылкой. Если сгенерированная ссылка синтаксически верна, выглядит правдоподобно, но ведет на несуществующую статью регламента, весь ответ бракуется как опасная галлюцинация.
Добавьте к этому автоматический LLM-as-a-judge скрипт, который прогоняет ночные тесты на регрессию. Каждая новая версия нормативной базы, заливаемая в систему, может перекрыть старые правила. Если позавчерашний правильный ответ сегодня стал ложным, потому что вышел новый приказ, система должна отследить падение метрик до того, как этот ответ получит реальный гражданин. Вы строите конвейер верификации, где цена ошибки несоизмерима с классическим e-commerce.
Построить суверенный llm-rag-onprem, который не страшно выпустить к сотням тысяч граждан, — это не обернуть готовую нейросеть в красивый чат. Это изматывающая война с грязными исходными данными, криво оцифрованными приказами и борьба за каждый процент точности в векторном поиске.
Вы не пытаетесь создать искусственный интеллект, который умнее чиновника или может обойти регламент. Вы проектируете непробиваемый механизм прослеживаемости, который мгновенно достает нужную правовую норму из горы документов и переводит ее на понятный язык. Если система может доказать каждое свое слово конкретной ссылкой на закон — она готова к нагрузкам. Если начинает хотя бы минимально фантазировать от себя — выключайте инференс и идите переписывать алгоритм фактологического контроля.