Когда в компании тысячи регламентов, инструкций и статей базы знаний, проблема обычно не в отсутствии нужного ответа, а в том, что сотрудник не знает, где его искать и как сформулировать запрос. Локальная языковая модель может упростить поиск: понять вопрос обычными словами, найти подходящие фрагменты документов и кратко объяснить, что в них сказано.
Для такой системы модель не должна самостоятельно «знать» внутренние правила компании. Надёжнее связать её с поисковым индексом и просить отвечать только по найденным материалам. Этот подход часто называют генерацией с поисковым дополнением: сначала система извлекает источники, затем модель формулирует ответ на их основе. От качества поиска здесь зависит не меньше, чем от размера самой модели.
Как устроен поиск
Перед запуском документы собирают из внутренних хранилищ, очищают от дублей и приводят к формату, с которым может работать индекс. Важно сохранить не только текст, но и контекст: название документа, подраздел, дату или номер версии, владельца, статус действия и ограничения доступа. Если эти сведения потерять, ответ может опираться на устаревший регламент или выдать черновик за действующее правило.
Затем документы разбивают на фрагменты. Слишком крупный фрагмент захватывает много лишнего, а слишком мелкий может оторвать правило от условий и исключений. Например, пункт о сроке согласования без соседнего абзаца может не содержать оговорку для отдельных типов заявок. Поэтому размер и границы фрагментов подбирают под структуру материалов: учитывают заголовки, разделы и списки, а не режут текст только по одинаковому числу символов.
Для поиска часто объединяют два метода. Полнотекстовый поиск хорошо находит точные формулировки, номера документов и специфические термины. Векторный поиск подбирает фрагменты по смыслу, даже если пользователь описал правило другими словами. Их результаты можно объединить и дополнительно ранжировать, чтобы наверх попадали наиболее подходящие источники. Локальные модели применяют для создания векторных представлений, переоценки найденных фрагментов и подготовки ответа — в зависимости от выбранной архитектуры.
Зачем нужна именно локальная модель
Локальное размещение помогает контролировать, где обрабатываются запросы и документы, и не передавать их внешнему поставщику модели. Это бывает существенно для персональных данных, коммерческой тайны и внутренних процедур. Но слово «локальная» само по себе не гарантирует защищённость: нужно проверить, куда уходят журналы запросов, как устроены резервные копии и доступ администраторов, какие компоненты системы подключены к внешним сервисам.
Развёртывание внутри инфраструктуры даёт контроль над версиями модели и настройками обработки, но добавляет нагрузку на команду. Нужно обеспечить вычислительные ресурсы, обновление программного обеспечения, мониторинг и резервирование. Компактная модель может оказаться достаточной для переформулировки запроса или краткого ответа, но хуже справляться со сложными инструкциями. Большая обычно требует больше памяти и вычислительной мощности. Выбор проверяют на реальных задачах, а не только по общим тестам модели.
Что определяет качество ответа
Система должна учитывать права пользователя ещё до формирования ответа. Если сотруднику недоступен документ в исходном хранилище, поисковый слой не должен показать его фрагмент или пересказать его содержание. Одного фильтра в интерфейсе недостаточно: проверку доступа нужно встроить в процесс извлечения материалов и регулярно сверять с корпоративными группами и ролями.
Полезный ответ обычно содержит ссылки внутри корпоративной системы или точные реквизиты источника: название, версию, раздел и страницу, если она есть. Так сотрудник может проверить формулировку и открыть полный документ. Если система нашла несколько противоречащих друг другу правил, лучше показать это явно и указать даты или статусы источников, а не сводить их в уверенный, но неверный совет.
Нужно заранее определить, что делать, когда подходящих материалов нет. Модель должна сообщить, что не нашла подтверждения, либо предложить уточнить запрос. Просьба «ответь только по найденным документам» полезна, но не устраняет ошибки полностью: модель может неверно интерпретировать фрагмент или добавить вывод, которого в источнике нет. Поэтому возможность проверить основание ответа — не украшение интерфейса, а рабочий механизм контроля.
Как проверять систему до запуска
Для испытаний собирают набор типичных вопросов сотрудников и эталонных источников: например, где описан порядок закупки, кто согласует командировку, какие условия действуют для конкретной процедуры. Отдельно проверяют запросы с сокращениями, внутренними названиями, опечатками и неоднозначными формулировками. Важно оценивать не только гладкость ответа, но и то, нашёл ли поиск нужный документ, верно ли указана версия и не раскрыты ли материалы за пределами прав пользователя.
Пилот разумно начать с ограниченного набора актуальных документов и одной группы пользователей. Такой запуск выявляет проблемы, которые сложно заметить на тестовых примерах: устаревшие копии в разных папках, сканы без распознанного текста, непоследовательные названия разделов. Обратная связь сотрудников помогает пополнять тестовый набор и улучшать индекс, но найденные ошибки стоит разбирать по причине: проблема может быть в документе, разбиении на фрагменты, поиске, правах или генерации.
Локальная языковая модель особенно полезна там, где сотрудники тратят время на навигацию по разрозненным внутренним материалам. Она не заменяет владельцев регламентов и не делает противоречивые документы согласованными. Практическая ценность появляется, когда поиск находит актуальный источник, соблюдает права доступа и позволяет быстро проверить, на каком основании сформулирован ответ.
