Данные готовы к внедрению ИИ, если они существуют в электронном виде, актуальны, не противоречат друг другу и к ним есть доступ. Проверяется это не опросом сотрудников, а на случайной выборке реальных материалов — именно на ней обычно и обнаруживается, что регламенты устарели, существуют в нескольких редакциях или расходятся с тем, как на самом деле работают люди. Проверка занимает часы, а её отсутствие способно обесценить весь проект.
Четыре условия готовности
Формулировка «у нас много данных» не говорит о готовности ничего. Значение имеют четыре свойства, и слабое место определяется по худшему из них.
Электронный вид. Информация существует в файлах, а не на бумаге и не в голове у сотрудника. Отсканированный без распознавания документ — это картинка, а не текст; для ИИ он ближе к бумаге, чем к данным.
Актуальность. Материалы соответствуют сегодняшнему порядку работы. Регламент двухлетней давности, по которому давно никто не работает, хуже отсутствия регламента: система будет уверенно отвечать по нему, и ошибку заметят не сразу.
Непротиворечивость. На один вопрос в материалах существует один ответ. Если инструкция говорит одно, приказ — другое, а практика третье, модели неоткуда взять правильный вариант; она выберет любой.
Доступность. К данным есть технический доступ и разрешение их использовать. Сюда же относятся ограничения закона: если в материалах персональные данные, требования к их обработке определяют архитектуру решения — см. «152-ФЗ и нейросети».
Условия не равнозначны. Отсутствие электронного вида — препятствие техническое, оно решается работой. Противоречивость — препятствие содержательное, и решить его может только человек, имеющий право сказать, какая версия правильная.
Почему опрос не работает, а выборка работает
Спросите руководителя, в порядке ли документы, — почти всегда услышите, что в целом да. Это не обман: он описывает то, как система задумана, а не то, чем она стала. Расхождение между замыслом и состоянием накапливается годами и незаметно изнутри.
Единственный надёжный способ — посмотреть на реальные материалы. Причём именно на случайные, а не на те, которые вам подберут: подобранные примеры всегда в порядке, потому что отбирались по признаку «вот хороший пример».
Практическое правило: выборка должна быть срезом, а не витриной. Возьмите обращения за произвольную неделю, документы за случайный месяц, действующие инструкции по списку — и смотрите, что там на самом деле.
Как провести проверку за несколько часов
Проверка простая и не требует технических навыков.
- Соберите 20–30 реальных вопросов из процесса — тех, что действительно задают. Из переписки, тикетов, журнала обращений.
- Найдите на каждый ответ в имеющихся материалах. Не по памяти эксперта, а именно в документах — так, как это будет делать система.
- Отметьте, что произошло с каждым вопросом: ответ нашёлся однозначно; нашёлся, но в нескольких противоречащих местах; нашёлся в устаревшем документе; не нашёлся вообще; нашёлся только в голове у эксперта.
Результат этого получасового упражнения обычно оказывается отрезвляющим и всегда полезным. Доля вопросов, на которые в материалах есть однозначный актуальный ответ, — это и есть верхняя оценка качества будущего решения. Модель не придумает того, чего в данных нет; она либо ответит неверно, либо, если система построена правильно, честно сообщит, что ответа не нашла.
Этот же набор вопросов позже пригодится как основа проверочной выборки для PoC.
Типичные диагнозы
| Что обнаружилось | Что это значит | Что делать |
|---|---|---|
| Документы на бумаге или в сканах без текстового слоя | Данных для ИИ фактически нет | Оцифровка и распознавание — отдельный этап до проекта |
| Несколько редакций одного документа | Система не сможет выбрать верную | Определить действующую версию, остальные убрать из корпуса |
| Регламенты расходятся с практикой | Правильный ответ существует только у людей | Зафиксировать реальный порядок письменно |
| Ответы есть, но разбросаны по почте и чатам | Корпус не собран | Свести в единый источник |
| Прямые противоречия между документами | Нет одного правильного ответа | Решение принимает владелец процесса, не подрядчик |
| Данные есть и в порядке | Можно переходить к проверке | Discovery и PoC |
Самый частый реальный диагноз — не «данных нет», а «данные есть, но правильный ответ из них не выводится однозначно». Это хорошая новость: проблема решаемая, и решается она редакторской работой, а не технологией.
Сколько стоит привести данные в порядок
Честный ответ: часто это основная статья затрат проекта, особенно при разнородном корпусе. Причина в том, что работа плохо автоматизируется — определить, какая редакция инструкции действует и что делать с противоречием, может только человек, знающий предмет и имеющий полномочия решать.
Отсюда практический вывод, который экономит деньги: не нужно приводить в порядок все данные компании. Нужен только тот участок, который относится к выбранному процессу. Попытка навести порядок везде превращает ИИ-проект в бессрочный проект документооборота и обычно хоронит оба. Один процесс — один ограниченный корпус — понятный объём работы.
Как этот корпус собирается технически, разобрано в статье «Подготовка базы знаний для ИИ».
Что делать, если данные не готовы
Это не приговор проекту, а уточнение его содержания. Возможны три сценария.
Данные нужно собрать и согласовать. Проект начинается с этапа подготовки корпуса, ИИ-часть сдвигается. Срок увеличивается, но результат достижим — и, что важно, упорядоченная база знаний полезна сама по себе, даже если ИИ-часть потом отложат.
Данных для этого процесса нет в принципе. Знание существует только у людей и не формализовано. Тогда честный вывод — выбрать другой процесс для первого проекта, а этот отложить. Хорошие кандидаты для старта разобраны в статье «Как выбрать процесс для первого ИИ-проекта».
Данные есть, но их нельзя передавать вовне. Ограничение не запрещает проект, а определяет архитектуру: локальное развёртывание, российский сервис или маскирование данных до передачи.
Готовность — это не про объём
Распространённое заблуждение: чтобы ИИ работал, нужно много данных. Для решений, отвечающих по документам, объём почти не имеет значения — важны актуальность и однозначность. Небольшой, выверенный, непротиворечивый корпус даёт лучший результат, чем гигабайты разнородных файлов, среди которых лежат три редакции одного приказа.
Более того, лишние данные вредят: чем больше в корпусе устаревшего и противоречивого, тем выше шанс, что система найдёт и уверенно процитирует именно это. Отсюда контринтуитивная рекомендация — на старте корпус чаще нужно сокращать, а не наращивать.
Частые вопросы
Сколько данных нужно, чтобы внедрить ИИ?
Для решений, отвечающих по документам, объём почти не важен — важны актуальность и однозначность. Небольшой выверенный корпус работает лучше большого разнородного, потому что в последнем система находит устаревшие и противоречивые фрагменты и уверенно на них ссылается. Требование «сначала накопим данные» обычно относится к задачам обучения собственных моделей, а не к типовым сценариям внедрения.
Как понять, что данные готовы, без технических специалистов?
Взять 20–30 реальных вопросов из процесса и попробовать найти на каждый ответ в имеющихся документах — именно в документах, а не по памяти эксперта. Доля вопросов с однозначным актуальным ответом и будет верхней оценкой качества будущего решения. Это упражнение занимает несколько часов и не требует никаких технических навыков.
Что делать, если документы противоречат друг другу?
Решить, какая версия действует, — и это решение принимает владелец процесса, а не подрядчик и не модель. Технических способов выбрать правильный вариант из двух противоречащих не существует: если человек не может сказать, какой ответ верный, система тем более не сможет. Устранение противоречий — обязательная работа до внедрения, и обычно самая трудоёмкая.
Нужно ли оцифровывать весь архив?
Нет, и попытка сделать это — частая причина того, что проект не доходит до ИИ-части. Оцифровывается только тот участок, который относится к выбранному процессу, и только та глубина, которая реально используется в работе. Документы, к которым не обращаются, не нужны системе, отвечающей на текущие вопросы.
Кто должен приводить данные в порядок — мы или подрядчик?
Техническую часть — сбор, распознавание, разметку, нарезку на фрагменты — может взять подрядчик. Содержательную часть — какая редакция действует, как разрешается противоречие, что считается правильным ответом — только заказчик. Это разграничение стоит зафиксировать заранее, потому что попытка передать содержательные решения исполнителю приводит к тому, что он принимает их наугад.
Что дальше
Проверка данных — часть discovery; общий порядок работ разобран в «Этапы внедрения ИИ в компании». Как собрать корпус после проверки — «Подготовка базы знаний для ИИ». Почему система уверенно отвечает неверно, когда в данных нет ответа, — «Почему нейросеть выдумывает ответы». Полная картина — в опорной статье «Внедрение ИИ в бизнес».
Диагностика данных и оценка объёма подготовки входят в аудит процессов перед разработкой и внедрением ИИ.