Локальный LLM-ассистент: пилот за 4 недели для сотрудников

С чего начать: проблема, цель пилота и границы

Начните не с выбора модели, а с одной конкретной боли. Кому именно нужен ассистент: поддержке, юристам, закупкам, HR, ИТ-сервису? И какие 1-2 задачи каждый день съедают больше всего времени: поиск ответа в регламентах, подготовка письма, разбор заявки, объяснение политики.

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

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

Чтобы не спорить в конце, зафиксируйте базовые договоренности:

• кто участвует в пилоте и какие у них типовые вопросы (5-10 примеров)
• цель в цифрах: экономия времени, снижение ошибок, рост скорости ответа
• границы данных: какие папки и базы можно использовать, а какие нельзя
• риски и стоп-условия: когда пилот приостанавливается
• формат результата: отчет, демо, решение о масштабировании

Отдельно назначьте роли. Нужен владелец продукта (со стороны бизнеса), который принимает решения по сценариям и приоритетам, и владелец данных, который отвечает за актуальность документов и правила доступа. Со стороны ИТ обычно нужен ответственный за инфраструктуру и безопасность. Если пилот делается на своих серверах, заранее проверьте, где он будет жить (например, в вашем ЦОД), и кто будет поддерживать его после теста. Часто это делают вместе с системным интегратором, который умеет собрать пилот на локальной инфраструктуре и быстро довести его до измеримого результата.

Выбор сценариев: где быстрее всего будет эффект

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

Как найти 2-3 сценария с понятной выгодой

Соберите 20-30 реальных обращений и операций за последнюю неделю: письма, заявки в сервис-деск, сообщения в чатах, комментарии в задачах. Затем отберите 2-3 сценария, где экономия времени очевидна и проверяема.

Обычно подходят задачи, которые:

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

Не берите задачи, где юридически значимая точность нужна с первого раза без проверки (например, финальные формулировки договоров или официальные ответы, которые нельзя вычитывать человеком). Это не запрет на ИИ, просто для 4-недельного пилота риски и согласования часто съедают сроки.

Кого подключать и как формулировать результат

Лучше выбрать одну команду или 2-3 роли внутри одного процесса, чтобы не распыляться. Например: HR (ответы на вопросы сотрудников), IT (типовые заявки), закупки (проверка комплектности заявки по правилам).

Для каждого сценария сформулируйте результат одним предложением: «Ассистент готовит черновик ответа или заявки по нашим правилам за X минут, а сотрудник проверяет и отправляет». Это станет опорой и для метрик, и для честной оценки пилота.

Данные и датасеты: что подготовить за неделю

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

Начните с источников, где уже есть готовые ответы и формулировки. Обычно достаточно нескольких типов материалов: пошаговые инструкции и регламенты, шаблоны писем и заявок, база знаний поддержки (FAQ и типовые решения), политики и стандарты (например, ИБ, закупки, кадры), а также справочник терминов и сокращений, чтобы ассистент «говорил на вашем языке».

Параллельно отсеките то, что в датасет попадать не должно. Не берите персональные данные, коммерческие секреты, сырой экспорт переписок и документы «на всякий случай». Если материал не нужен для типовых вопросов, он увеличивает шум и риск.

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

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

Минимальный набор для старта: 20-40 документов или 50-150 страниц текста, но вычищенных и понятных. После пилота расширяйте пакет по фактическим запросам: добавляйте то, что спрашивают чаще всего, вместо попытки загрузить «все сразу».

Простая архитектура пилота: как это будет работать

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

Начните с режима работы. Первый вариант - ассистент только ищет по документам и показывает найденные фрагменты с источниками. Второй вариант - локальный LLM-ассистент формулирует ответ, но строго опирается на найденные фрагменты (чтобы не фантазировать и чтобы ответ можно было проверить).

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

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

Чтобы пилот был управляемым, нужны журналы. Они помогают разбирать ошибки и подтверждать эффект:

• кто задавал вопрос (учетная запись и роль)
• время и канал (веб-чат или мессенджер)
• текст запроса и итоговый ответ
• какие документы использовались (названия и версии)
• отметка сотрудника: полезно или нет

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

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

Ограничения доступа и безопасность без сложных терминов

Если вы делаете локальный LLM-ассистент, главное правило простое: ассистент не должен «видеть» больше, чем человек, который задает вопрос. Тогда пилот можно запускать даже на чувствительных процессах, не превращая проект в бесконечное согласование.

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

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

Ограничения лучше задать заранее и явно: запретные темы (персональные данные, зарплаты, медкарты, коммерческие условия), запретные команды (массовые выгрузки, «покажи все», экспорт в файлы), лимиты (сколько документов за раз, длина ответа, количество запросов), правила цитирования (название внутреннего документа и дата версии).

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

Политика хранения звучит скучно, но спасает пилот. Зафиксируйте, что сохраняется (вопросы, ответы, фрагменты контекста), как долго (например, 30-90 дней), и кто имеет доступ (обычно админ и владелец данных). Если пилот идет на инфраструктуре компании или на выделенных серверах внутри периметра, эти правила проще выдержать и подтвердить.

Подготовка знаний: чтобы ассистент опирался на ваши правила

Смысл пилота в том, чтобы локальный LLM-ассистент отвечал не «из головы», а по вашим документам и внутренним правилам. Тогда ответы проверяемы: всегда видно, на какой регламент, инструкцию или шаблон он опирается.

RAG: ответы на основе ваших документов

Для пилота обычно хватает подхода RAG: ассистент сначала находит в вашей базе 3-7 подходящих фрагментов (например, из регламентов, FAQ, шаблонов писем), а затем формирует ответ строго по найденному. Это особенно полезно там, где важны точные формулировки: закупки, кадровые процессы, ИТ-заявки, внутренние согласования.

Практичный пример: сотрудник спрашивает «какие документы нужны для закупки у единственного поставщика?» Ассистент достает нужный раздел внутреннего положения, отвечает шагами и в конце уточняет недостающие данные (сумма, источник финансирования, тип товара) вместо длинных рассуждений.

Правила ответа, шаблоны и обязательные предупреждения

Чтобы ответы были одинаково полезны в разных отделах, заранее задайте правила формата. Например: отвечать коротко (5-10 строк, затем «Следующие шаги»), при нехватке данных задавать 2-3 уточняющих вопроса, перечислять документы и согласующих, добавлять пометку «нужна проверка человеком» там, где риск ошибки выше, и показывать, из каких материалов взята информация (название документа и раздел).

Шаблоны тоже лучше подготовить заранее: для юристов подойдет структура «факты -> риски -> что согласовать», для бухгалтерии - «проводки/документы/сроки», для ИТ - «симптом -> проверка -> решение -> когда эскалировать». Это снижает разнобой и ускоряет привыкание.

Чтобы знания не устаревали, назначьте ответственного и простой процесс обновления: один владелец на каждый набор документов (закупки, HR, ИТ), периодичность (раз в 2 недели на пилоте, дальше раз в месяц), единый формат (PDF/Doc + дата версии в названии), короткий список «что изменилось» для быстрой проверки качества.

Критерии успеха и измерение качества

Пилот легко «почти понравится всем», если не договориться, что именно считается успехом. Для локального LLM-ассистента это особенно важно: он работает с внутренними правилами и документами, поэтому качество нужно измерять так же строго, как и безопасность.

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

Дальше определите «эталон». Это не всегда идеальный текст. Иногда правильный результат - верный маршрут: куда отправить заявку, какой шаблон выбрать, какие поля заполнить, какие документы приложить. Например, в сценарии «закупка» эталоном могут быть шаги согласования и список обязательных вложений, а не длинное объяснение.

Метрики, которые дают измеримый результат

Выберите 3-4 показателя и не усложняйте:

• доля полезных ответов (сотрудник смог продолжить работу)
• время до решения (сколько минут прошло от вопроса до следующего шага)
• доля эскалаций (когда пришлось идти к человеку или в другой отдел)
• удовлетворенность (короткая оценка после ответа: «полезно/неполезно»)

Обязательно тестируйте на разных ролях и уровнях доступа. Один и тот же вопрос от бухгалтера и от менеджера по закупкам может требовать разной глубины ответа и разного набора документов. Если ассистент «видит лишнее» или, наоборот, всегда отвечает общими словами, пилот будет казаться успешным только на бумаге.

Как фиксировать ошибки, чтобы быстро улучшать

Ошибки лучше записывать в одном месте и одинаковым способом:

• категория: неверный факт, устаревшее правило, не тот маршрут, «не понял вопрос»
• источник: какой документ подвел (или данных не было)
• роль и доступ: кто спрашивал и что ему было разрешено
• приоритет: блокирует работу или просто неудобно

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

Пошаговый план пилота за 4 недели

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

Неделя 1: договориться о целях и границах

Выберите 2-3 сценария, где ответ проверяется по документам (поиск правил, шаблонов, регламентов, типовых ответов). Назначьте владельца сценария от бизнеса и владельца данных. Сразу зафиксируйте критерии успеха: какие вопросы ассистент должен закрывать, какие ответы считаются ошибкой, и что точно запрещено (например, персональные данные, коммерческие условия, черновики договоров).

Недели 2-4: собрать, настроить, проверить

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

• Неделя 2: очистка документов, единые названия и версии; роли доступа; прототип с логированием запросов
• Неделя 3: тестовый набор из 50-100 вопросов; правки промпта и формата ответа; список «опасных» тем и отказов
• Неделя 4: пилот на группе 10-30 человек; сбор метрик; решение: масштабировать, переделать сценарий или остановить

Чтобы пилот не расползался, задайте ежедневный ритм (15 минут достаточно) и держите короткий список блокеров: что сломалось сегодня, 3-5 примеров плохих ответов и почему они плохие, одна быстрая правка (инструкция, документ, доступ), кто и к какому сроку делает следующий шаг.

Если к концу 4 недели вы видите рост доли полезных ответов, снижение времени на типовые вопросы и нет инцидентов по доступам, пилот можно расширять на новые сценарии.

Пример пилота: ассистент для закупок и согласований

Хороший «быстрый» пилот - помощь там, где каждый день одни и те же вопросы, много переписок и много ошибок в формулировках. Закупки и согласования часто подходят идеально: регламенты сложные, документов много, а время теряется на уточнения.

Сценарий простой: сотрудник закупок задает вопрос обычными словами, а локальный LLM-ассистент отвечает по внутренним правилам и шаблонам. Он не «придумывает», а опирается на подготовленные документы и выдает понятный план действий.

Для пилота достаточно ограниченного набора материалов: положения и регламенты по закупкам, чек-листы по комплекту документов, типовые письма и ответы на частые вопросы. Важно заранее договориться, что именно считается «источником истины», и убрать дубли.

Примеры запросов без кодов, номеров пунктов и канцелярита:

• «Нужно купить сервер. Какие шаги и кто согласует?»
• «Какой пакет документов нужен для закупки у единственного поставщика?»
• «Дай шаблон письма на запрос КП и что в нем обязательно указать»
• «Сколько дней занимает согласование и на каких этапах чаще всего возвращают?»

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

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

Такой пример легко «приземлить» в реальную организацию. В компаниях со строгими требованиями к прозрачности цепочки поставок и локальной инфраструктуре, например в контуре GSE.kz, обычно важно, чтобы ассистент точно повторял внутренние правила и не раскрывал лишнее. Поэтому в пилоте сразу задают роли доступа: закупки видят шаблоны и чек-листы, а финансовые лимиты или договоры доступны только тем, кому положено.

Частые ошибки пилота и как их избежать

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

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

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

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

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

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

Практичный способ снизить риск:

• сузьте пилот до одного процесса и измеримого результата (время ответа, число обращений в поддержку, доля решенных запросов)
• наведите порядок в источниках: оставьте одну актуальную версию, добавьте дату, владельца и статус (актуально или архив)
• назначьте ответственного за контент и график обновлений (например, раз в 2 недели)
• соберите тестовый набор из 30-50 реальных вопросов и заранее договоритесь, как ставится оценка ответа
• настройте права по ролям и проверьте их на 3-5 типовых пользователях, прежде чем расширять доступ

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

Короткий чек-лист и следующие шаги после пилота

Пилот ценен тем, что дает ясный ответ: приносит ли локальный LLM-ассистент пользу вашим сотрудникам и процессам. Перед финальным отчетом проверьте, что вы оценивали результат по заранее понятным правилам, а не по ощущениям.

Короткая проверка:

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

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

Дальше чаще всего выбирают один из трех вариантов: масштабировать на похожие команды и добавить 1-2 сценария; сузить пилот до одного сценария и довести качество на тестовом наборе; остановить без потерь, зафиксировав выводы и сохранив датасеты и метрики, чтобы вернуться позже.

Следующий практический шаг - подобрать локальную инфраструктуру и поддержку под ваш контур: где будут стоять серверы, кто отвечает за обновления, резервное копирование и доступы. Для пилота часто достаточно выделенных серверов и базовой интеграции, а дальше решение развивается поэтапно. Если нужен вариант с развертыванием на месте и сопровождением, это можно обсудить с GSE.kz (gse.kz): от подбора серверов и рабочих станций до системной интеграции и 24/7 поддержки.