Может ли LLM отвечать жителям: база знаний, проверка фактов и передача оператору

Короткий ответ

Да, LLM может корректно отвечать жителям на типовые информационные запросы — но только при трёх условиях: ответы строятся на актуальной и курируемой базе официальных документов, каждый факт проверяется по источнику с указанием ссылки, а неопределённые, чувствительные и юридически значимые вопросы передаются человеку. Модель — это лишь интерфейс к знаниям, а не источник истины. В проверенных внедрениях боты закрывают 85–99% таких обращений, но решения и правовые позиции остаются за специалистами.

Главные выводы

Источник истины — курируемая база знаний из официальных документов, а не обучение модели: «качество курирования важнее объёма корпуса».
RAG (генерация с поиском по базе) снижает галлюцинации, стоимость и риск утечки персональных данных по сравнению с дообучением модели.
Каждый ответ должен проверяться по источнику: цитаты, ссылки на страницы и порог достоверности для автоматического отклонения сомнительных формулировок.
Эскалация к человеку — часть архитектуры и контракта: нужен видимый шаг для жителя, номер обращения и обещанный срок ответа.
Человек остаётся ответственным за правовые решения, обработку персональных данных и сложные дела; бот закрывает рутинные информационные вопросы.
Реальные программы разделяют трафик: боты обслуживают высоконагруженные справки, а живые операторы — привязанные к конкретному участку и имуществу кейсы.
Успех измеряется не только точностью, но и долей эскалаций, повторных обращений и скоростью ответа.

Короткий ответ: да, но в строго очерченной зоне ответственности

Практика крупных запусков показывает, что вопрос «может ли LLM отвечать жителям» правильнее сформулировать иначе: «при каких условиях ей можно доверять». Британский GOV.UK Chat, протестированный более чем на 10 000 пользователей с 26 000 вопросов, довёл точность ответов с 76% до 90%, отвечая строго по опубликованным материалам портала. Лондонский боро Баркинг и Дагенем обслуживает около 4 450 диалогов в месяц с 93% положительных оценок пользователей, параллельно разгружая телефонную линию.

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

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

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

Сначала — база знаний, а не выбор модели

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

Известный негативный пример — нью-йоркский MyCity Chatbot для юридических консультаций жителей: за три года его неоднократно критиковали за рекомендации, противоречащие законодательству, и после смены администрации проект, на который потратили более 600 000 долларов, закрыли. Как объясняют эксперты, когда модель опирается на общие знания из интернета, а не на выверенную локальную базу, она может «уверенно» выдумать юрисдикцию, срок или дату — и житель это обнаруживает при двойной проверке у реальной администрации.

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

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

Проверка фактов: почему RAG, а не дообучение

Чтобы ответы не противоречили действующим нормам, применяют генерацию с поиском по базе (RAG): система сначала находит фрагменты документов, релевантные вопросу, а затем формулирует ответ только на их основе. Исследователи отмечают, что RAG снижает «галлюцинации», повышает фактическую согласованность и в разы дешевле дообучения (fine-tuning), которое, как показали сравнения, способно давать более «гладкие», но менее достоверные формулировки. RAG также позволяет развернуть систему полностью внутри контура администрации, не отправляя чувствительные данные на сторонние платформы.

Дополнительный слой проверки — обязательные ссылки на источники. Румынский пилот пропускал каждый ответ через многоагентную проверку перед выдачей пользователю. GOV.UK специально строит ответы так, чтобы их легко было перепроверить по первоисточнику, и честно предупреждает, что ИИ может ошибаться. Автоматическая оценка точности (в том числе силами предметных экспертов) и доля ответов «в зоне действия» — базовые метрики качества.

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

Требуйте от системы цитаты и прямые ссылки на документы в каждом ответе.
Задайте порог достоверности: ниже него бот не формулирует утверждение, а уточняет вопрос или передаёт оператору.
Ведите журнал версий документов и привязывайте ответы к дате актуальности редакции.

Архитектура доверия: эскалация и передача оператору

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

В округе Принс-Уильям (США) этот принцип реализован в модели «фронтальной двери»: бот Will за год обработал около 40 000 обращений (чаще всего по налогам и недвижимости), голосовой агент Willow после рабочих часов принял 8 885 звонков, но более 40% взаимодействий остались за живыми аналитиками, которые ведут сложные, привязанные к конкретной собственности вопросы. В Риверсайде (Калифорния) чат Rivy на 98,7% верно подбирает городской ресурс, а остаток объёма плавно передаётся человеку в рабочее время.

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

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

Метрики, мониторинг и границы автоматизации

Измеряйте не только точность, но и поведение системы в реальных условиях: долю вопросов, на которые бот отвечает уверенно; долю эскалаций; скорость первого ответа; повторные обращения. Баркинг и Дагенем, например, дополнительно отслеживает снижение числа общих обращений и звонков, а Риверсайд — долю звонящих, выбирающих ИИ, и разрешение вопроса с первого контакта (89,9% для голосового агента).

Отдельная зона риска — безопасность и защита данных. Публичные боты сталкиваются с попытками «взломать» их инструкции: у GOV.UK Chat за два пилота зафиксировано 508 таких попыток, все были заблокированы, но риск остаётся постоянным и требует управления. Жители могут пытаться использовать бота вне его назначения — например, для выполнения домашних заданий, как в Риверсайде, — поэтому нужны жёсткие рамки области действия.

Наконец, определите, что автоматизировать нельзя: юридически обязывающие разъяснения, решения по существу обращения, работу с персональными данными без надлежащей аутентификации. Здесь роль LLM — подготовить черновик и собрать контекст, а финальное слово остаётся за специалистом. Такой подход не только снижает риски, но и повышает доверие: житель знает, что в трудной ситуации до него достучится человек.

Ежеквартально пересматривайте пороги доверия и базу знаний по данным эскалаций.
Ведите реестр инцидентов и попыток выхода за рамки области действия.
Сохраняйте живого оператора в рабочее время — это обязательное условие доступности услуги.

Практический инструмент

Чек-лист готовности сервиса «LLM отвечает жителям»

Используйте этот чек-лист перед запуском или аудитом действующего сервиса. Каждый пункт — проверяемое условие; если хотя бы несколько не выполняются, запуск безопаснее отложить или сузить область действия.

Составлен перечень типовых вопросов жителей и определён перечень услуг, по которым разрешён прямой ответ.
База знаний собрана из действующих официальных документов, у каждого раздела есть владелец и дата пересмотра.
Из базы исключены внутренние инструкции, устаревшие редакции и любые персональные данные.
Каждый ответ содержит цитату и ссылку на первоисточник, а система умеет проверять достоверность по документу.
Задан количественный порог доверия: ниже него бот не утверждает, а уточняет вопрос или передаёт оператору.
Определены маршруты эскалации для каждого типа обращений с номером кейса и обещанным сроком ответа.
Передача оператору включает контекст диалога, без повторного опроса жителя.
Чувствительные темы (жалобы, обжалование, персональные данные, признаки ЧП) передаются человеку по умолчанию.
Настроен мониторинг: точность, доля эскалаций, повторные обращения, скорость ответа, инциденты безопасности.
Живой оператор доступен в рабочие часы, а предупреждение о возможных ошибках ИИ показано пользователю.

Частые вопросы

Почему муниципальные чат-боты чаще всего проваливаются на практике?

Причина редко в самой модели — чаще в отсутствии рабочей эскалации. Жители задают вопросы вне зоны обучения: диалекты, обрывки фраз, бытовая лексика вместо бюрократической. Когда бот не знает ответа и не умеет плавно передать диалог человеку, обращение зависает, а доверие падает ко всему сервису. Устойчивая эскалация требует трёх компонентов: понятного сигнала жителю, конкретного получателя (оператор, тикет-система, номер для обратного звонка) и документированной передачи с идентификатором кейса.

Дообучать модель или использовать RAG для ответов жителям?

Для муниципальных справок, как правило, эффективнее RAG (генерация с поиском по базе). Система сначала находит релевантные фрагменты действующих документов и формулирует ответ только на их основе, что снижает галлюцинации и позволяет показывать ссылки на первоисточник. RAG также в разы дешевле дообучения и допускает развёртывание внутри контура администрации без передачи данных на сторонние платформы. Дообучение может давать более «гладкий» язык, но исследователи фиксировали у него больше фактических ошибок; его стоит рассматривать для узких закрытых задач, а не для публичного консультирования.

Как не дать модели «выдумать» местные правила, сроки и даты?

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

В каких случаях бот обязан передать разговор оператору?

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

Является ли ответ языковой модели юридически обязывающим?

Нет. Ответ LLM — это информационная справка, а не юридически обязывающее административное решение или официальное разъяснение. Ответственность за правовые позиции, решения по существу обращения и корректную обработку персональных данных несёт администрация и её специалисты. Поэтому для чувствительных и юридически значимых тем роль модели — собрать контекст и подготовить черновик, а финальное решение и официальный ответ остаются за человеком. Этот принцип стоит закрепить и в интерфейсе, и в регламентах.

Какие метрики показывают, что сервис действительно хорош?

Ключевые метрики: точность ответов (оценка экспертами и автоматическими средствами, например 90% у GOV.UK Chat), доля вопросов, на которые бот отвечает уверенно (в зоне действия), доля успешных эскалаций, повторные обращения, скорость первого ответа и удовлетворённость пользователей. Дополнительно измеряйте разгрузку канала: снижение числа звонков и общих обращений. Риверсайд отслеживает долю выбора ИИ звонящими и разрешение вопроса с первого контакта (89,9%), а Баркинг и Дагенем — успешность сессий (93% положительных оценок).

Источники и дополнительные материалы

Источники проверены при подготовке страницы. Изменяемые даты, нормы и цены уточняйте у первоисточника.

5 things we learned testing GOV.UK Chat: an AI assistant for governmentGovernment Digital Service (GOV.UK)
Barking and Dagenham AI Search and Webchat - ToolsUK Government AI (ai.gov.uk)
Prince William County 311 Marks One Year of Service, Expands Access and CapabilitiesPrince William County Government
AI Bright Spot: Assisting residents with an AI chatbot in Riverside, CaliforniaPartnership for Public Service, AI Center for Government
Can Municipal AI Be Trusted? Lessons from an Agile Pilot in RomaniaInterreg Danube Region Programme (PilotInnCities)
От чат-ботов до мультиагентных системВедомости. Город
从人工窗口到智能问答：大语言模型与RAG技术重塑政务服务HKU Business School