Внутренний ассистент, которого мы собирали для строительной группы компаний, знает 155 файлов — это 798 кусков текста, разложенных по 20 отделам. Цифры звучат солидно. Но первая сборка отвечала мимо, и виноват был не ИИ.
Мы просто ссыпали в базу всё, что лежало в общей папке. Регламенты вперемешку с презентациями, три редакции одного положения, сканы приказов картинками. Модель честно нашла то, где нужные слова встречались чаще, — и это оказалась презентация трёхлетней давности.
База знаний — не файлопомойка с поиском. Это отдельный продукт, который надо спроектировать, собрать и потом кормить. Ниже — как мы это делаем сейчас, после нескольких заходов на грабли.
Что в базу класть нельзя
Сканы без текстового слоя. PDF, у которого каждая страница — картинка. Поиск по нему находит ровно ничего. Проверка занимает пять секунд: откройте файл и попробуйте выделить строку мышью. Не выделяется — нужен OCR. Мы гоняем такие файлы через Tesseract, и тут отдельная засада: русская модель из набора tessdata_fast битая. Движок на ней молча спотыкается, откатывается на английский и выдаёт латинскую кашу вместо текста. Брать надо tessdata_best, он весит около 15 МБ.
Презентации. Слайд — это тезис без контекста. «Срок согласования — 3 дня» на слайде живёт без ответа на вопрос «согласования чего и кем». Ассистент вытащит эту строку и уверенно отдаст её клиенту.
Переписка целиком. Выгрузка почты за год добавляет объём и отнимает точность: половина писем — договорённости, которые давно отменили.
Файлы с именами вроде «Положение_финал_2_испр(1).docx». Пока человек не скажет, какая из четырёх редакций действующая, ассистент будет цитировать случайную.
Excel с объединёнными ячейками и формулами. Разбирается в кашу. Если данные важны — выгружайте плоскую таблицу: одна строка, один объект, никаких шапок в три этажа.
Что годится
Скучные вещи. Действующие регламенты и инструкции в DOCX. Прайс-листы плоской таблицей. Ответы на частые вопросы, написанные человеком, а не собранные из переписки. Технические паспорта. Условия работы: гарантии, сроки, зоны выезда, что входит в стоимость и что не входит.
Стартовать проще всего с двадцати вопросов, которые сотрудники задают друг другу чаще всего. Не с документов — с вопросов. Соберите их у руководителя отдела за один разговор, потом найдите, где на каждый лежит ответ. Половину ответов вы не найдёте нигде: они живут в голове у Марины из сметного. Вот эти полчаса с Мариной и есть самая ценная часть сборки базы.
Как резать документ на куски
ИИ не читает файл целиком. Система находит несколько подходящих фрагментов и уже по ним формулирует ответ. Значит, качество упирается в нарезку.
Плохой способ — резать вслепую по 1000 символов. Кусок начинается с середины таблицы и заканчивается на середине предложения; ответ получается обрубком.
Хороший способ — резать по заголовкам. Один смысловой раздел — один фрагмент. Если раздел большой, делим по подзаголовкам с перекрытием в пару предложений, чтобы мысль не рвалась. Рабочий ориентир по размеру — 300–800 слов на кусок.
| Формат исходника | Чем разбираем | На что смотреть |
|---|---|---|
| DOCX | python-docx | заголовки стилями, а не «жирным вручную» |
| PDF текстовый | PyMuPDF | колонтитулы попадают в каждый чанк — вычищать |
| PDF-скан | Tesseract + tessdata_best | проверить выборочно 5 страниц глазами |
| XLSX | openpyxl | развернуть объединённые ячейки до плоской таблицы |
| Почта, чаты | руками | сначала выжимка, потом в базу |
Ещё один момент, который экономит много нервов: заголовок раздела надо дописывать в начало каждого фрагмента. Тогда кусок «не более 5 рабочих дней» превращается в «Гарантийный ремонт → Сроки → не более 5 рабочих дней», и поиск начинает попадать.
Шапка файла: шесть строк, которые решают половину проблем
В начало каждого документа базы мы ставим короткий блок:
- о чём документ — одной фразой;
- к какому отделу относится;
- с какой даты действует;
- кто владелец: фамилия, а не «отдел кадров»;
- откуда взяты цифры — приказ, договор, расчёт.
Шесть строк. Дают они сразу две вещи: поиск цепляется за них как за краткое содержание, а человек при разборе инцидента понимает, откуда прилетел кривой ответ.
Это же правило страхует от главной беды: ответ без источника проверить невозможно. У нас в инженерной платформе канон жёсткий — ни одного числа без ссылки на документ, откуда оно взято. Подробнее про это в статье где ИИ врёт и как это ловить.
Версии регламентов — главная головная боль
Компания живёт, регламенты меняются, старые редакции остаются лежать. И ассистент цитирует ту, которую нашёл.
Что делаем мы:
- в базе лежит только действующая редакция, архив хранится отдельно и в поиск не попадает;
- дата вступления в силу пишется в шапке документа и попадает в каждый фрагмент;
- если два документа противоречат друг другу, ассистент обязан сказать об этом прямо, а не выбирать удобный;
- раз в квартал — сверка списка документов базы со списком действующих приказов. Занимает час, ловит по 3–5 протухших файлов.
Автоматически «понять», какая редакция свежая, не получится. Дата файла врёт: её меняет любое сохранение. Порядок наводится руками один раз, дальше поддерживается по мере изменений.
У каждого раздела должен быть живой владелец
Это единственный пункт, без которого база гарантированно умрёт за квартал. Не «отдел отвечает», а конкретный человек с фамилией: раздел «Гарантия» — Иванов, раздел «Прайс» — Петрова. Владелец делает две вещи: подтверждает изменения в своём разделе и разбирает жалобы «ассистент ответил неправильно».
Мы у себя закрепили это на уровне процесса: у каждой части базы есть тот, кто её принимает, и отдельный контролёр, который проверяет чужую работу. Сам себя никто не принимает. Звучит бюрократично, но именно эта пара ролей держит качество базы, когда первый энтузиазм проходит.
Ещё нужна изоляция доступов. В корпоративном ассистенте у нас аккаунт на отдел: 20 отделов плюс директор, и бухгалтерия не видит договоры продаж. Изоляцию проверяли отдельно — это тот пункт, который надо тестировать, а не декларировать.
Люди спрашивают не теми словами
Регламент называет это «мобилизацией бригады на объект». Клиент пишет «сколько стоит выезд». Поиск по документам эти две формулировки не связывает никак, и ассистент честно отвечает «не нашёл», хотя нужное лежит на второй странице.
Лечится не магией, а списком синонимов, который ведётся руками. Мы держим его прямо в базе отдельным файлом: официальный термин, а рядом три-пять живых формулировок — как говорят клиенты, монтажники, менеджеры. Туда же идут расшифровки внутренних сокращений. «КС-2», «СКС», «ПНР» — в документах они на каждой странице, а новичок и клиент их не знают.
Пополняется список из логов. Раз в неделю смотрим вопросы, на которых ассистент развёл руками, и добрая половина оказывается не пробелом в базе, а разницей в словах.
Чтобы база не протухла
Живая база — та, у которой есть постоянный входящий поток изменений. Работают три канала:
- вопросы без ответа за неделю — коротким списком владельцам разделов, дальше их решение: дописывать или нет;
- жалобы «ответил неправильно» — разбирается каждая, и по итогу правится документ, а не промпт;
- изменения в компании: новый прайс, новая услуга, свежая редакция положения. Обновление базы должно быть вписано в процесс их утверждения, иначе про него просто забудут.
Часа-полутора в неделю на человека хватает. Меньше не выходит. Больше — сигнал, что база собрана криво, и надо возвращаться к структуре, а не героически её подпирать.
Отдельно про объём: расти база должна медленно. Сорок выверенных документов работают лучше четырёхсот «на всякий случай» — каждый лишний файл размывает поиск. Мы это видели на цифрах приёмки: после загрузки очередной пачки материалов точность на старых вопросах падала.
Приёмка: 20 вопросов, а не «вроде отвечает»
Перед запуском собираем список из двадцати реальных вопросов с заранее известными правильными ответами. Половина — простые, четверть — на стыке двух документов, ещё четверть — про то, чего в базе нет вообще (ассистент обязан честно сказать «не знаю»).
Прогон по этому списку занимает полчаса и даёт понятную цифру: 17 из 20. Дальше видно, что чинить. Без такого списка приёмка превращается в спор о вкусах, и запускается система, которой никто не доверяет.
Где это не работает
Скажу честно. База знаний не спасает, когда знаний в компании нет — есть 15 лет устной традиции. В такой ситуации ИИ-проект превращается в проект по написанию регламентов, и это нормально, но сроки другие: не две недели, а два-три месяца, и основную работу делают ваши люди, а не подрядчик.
Не работает и на быстро меняющихся данных. Остатки на складе, актуальные цены, статус заказа — это не база знаний, это интеграция с учётной системой. Пытаться держать их в документах бессмысленно: к моменту ответа цифра устареет.
Не ждите точности 100%. Реалистичный ориентир для хорошо собранной базы — 90–95% верных ответов на типовых вопросах, при условии что оставшиеся 5–10% ассистент честно отдаёт человеку, а не выдумывает.
И последнее: база не заменяет обучение сотрудников. Она отвечает на вопрос «где написано», а не на вопрос «как думать».
Провал, который стоил нам двух недель
Расскажу подробно, потому что ошибка типовая.
На одном из первых заходов мы нарезали документы механически — кусками по 1000 символов, как в большинстве примеров из интернета. В базе лежал прайс с таблицей: наименование, цена, срок, условия. Таблица длинная, и нарезка разрубила её посередине строки.
Дальше произошло вот что. Ассистент нашёл кусок, где было название нужной услуги. Цена в этом куске тоже была — только относилась она к следующей строке таблицы. Ответ выглядел абсолютно нормальным: услуга правильная, цифра правдоподобная, источник указан. Поймали случайно, когда человек полез в исходный файл.
Чинили так:
- таблицы вынесли из общего потока текста и стали резать построчно, каждая строка — отдельный фрагмент со своей шапкой;
- в каждый фрагмент дописали заголовок раздела и название колонок;
- добавили в набор проверочных вопросов пять штук именно про цены, с точными ожидаемыми цифрами;
- договорились, что цены вообще не живут в базе знаний долго — их место в учётной системе, а в базе только условия и порядок расчёта.
Две недели ушло на то, чтобы найти причину и перестроить нарезку. Если бы у нас с самого начала был список контрольных вопросов с точными ответами, поймали бы за час.
Чек-лист: что проверить перед стартом
- Есть ли у вас 20 вопросов, на которые ассистент обязан отвечать, и знаете ли вы правильные ответы?
- Какая доля документов — сканы? Проверьте выборочно: выделяется ли текст мышью.
- Сколько документов противоречат друг другу? Обычно находится две-три пары, и это нормально — важно решить, какой главнее.
- Назначен ли владелец у каждого раздела? Не отдел, а человек.
- Кто разбирает жалобы «ответил неправильно» и сколько времени в неделю на это заложено?
- Где проходит граница: что живёт в базе знаний, а что берётся из учётной системы?
- Как сотрудники будут спрашивать — в Telegram, в веб-кабинете, внутри CRM? От этого зависит, будут ли пользоваться вообще.
Частые вопросы
Модель обучается на наших документах? Нет. Документы лежат в поисковой базе, модель их не запоминает — она получает найденные фрагменты в момент вопроса и формулирует ответ по ним. Убрали документ из базы, и ассистент про него больше не знает.
Сколько документов нужно, чтобы начать? Хватает 15–30 на один отдел. Больше на старте вредно: труднее проверять качество и понять, что именно ломается.
А если документы обновляются каждую неделю? Нормальная ситуация. Обновление базы должно занимать минуты и делаться тем, кто правит документ, а не подрядчиком по заявке. Если для замены файла нужно писать в поддержку, база умрёт.
Можно ли дать доступ клиентам, а не только сотрудникам? Можно, но база для клиентов собирается отдельно. Внутренние регламенты, себестоимость и переписка туда попадать не должны — про это есть отдельный разбор.
С чего начать на следующей неделе
Возьмите один отдел, где чаще всего дёргают коллег вопросами. Соберите 20 вопросов и найдите на них ответы в документах. Приведите в порядок эти документы — шапка, действующая редакция, нормальные заголовки. Получится мини-база на 15–30 файлов, и уже на ней видно, взлетит ли идея у вас.
Дальше — то, что мы делаем чаще всего: подключаем такую базу к боту в Telegram, и сотрудник спрашивает как человека. Как это выглядит на живых процессах, показываем в наших кейсах. А если хотите понять, с какого участка вам вообще начинать, — приходите на AI-аудит: разберём процесс, посчитаем, что даст эффект первым, и скажем прямо, если база знаний в вашем случае не первый шаг.