По моему опыту, здесь и начинается большинство проблем. Данные в компании обычно есть, но они разбросаны между CRM, 1С, файловыми папками, электронной почтой, записями звонков и таблицами сотрудников, а правильный результат процесса нередко существует только в голове опытного специалиста.
«У нас много данных» ещё ничего не означает
Объём данных сам по себе не делает компанию готовой к внедрению ИИ. Миллион документов бесполезен, если среди них нельзя отличить актуальную редакцию от устаревшей, связать документ с конкретной операцией или понять, чем в итоге закончилась его обработка.
Для ИИ важны не только сами файлы или записи. Нужно понимать их происхождение, актуальность, назначение, ограничения доступа и связь с результатом процесса. В рекомендациях NIST по управлению рисками генеративного ИИ отдельно уделяется внимание происхождению данных, их качеству, конфиденциальности и документированию того, как они используются системой (NIST AI 600-1).
Представим транспортную компанию, которая хочет автоматически проверять перевозочные документы. В архиве могут храниться десятки тысяч накладных, актов и заявок, но для прототипа важнее получить небольшую репрезентативную выборку: хорошие и плохие сканы, документы разных перевозчиков, рукописные исправления, неполные комплекты и примеры реальных расхождений.
Именно на такой выборке можно понять, распознаёт ли система нужные поля, умеет ли сопоставлять документы между собой и замечает ли ошибки, которые действительно имеют значение для бизнеса. Большой архив пригодится позднее, а в начале он скорее мешает увидеть задачу.
Для разных задач нужны разные данные
Не существует универсального набора данных, после подготовки которого компания становится «готовой к ИИ». Требования зависят от того, какую операцию мы хотим изменить.
Для корпоративного ассистента по внутренним знаниям нужны действующие регламенты, инструкции, договорные шаблоны и справочники. При этом важно знать владельца каждого документа, дату обновления, область применения и права доступа, иначе ассистент начнёт уверенно смешивать старые и новые правила.
Для распознавания и проверки документов нужны примеры тех форматов, которые действительно приходят в компанию. Идеальные PDF из презентации поставщика почти ничего не говорят о том, как решение справится с фотографиями, перекошенными сканами, печатями, таблицами и плохо читаемыми реквизитами.
Для классификации обращений или контроля качества звонков понадобятся не только тексты и записи. Нужны понятные категории, критерии оценки и примеры решений, с которыми согласны специалисты бизнеса.
Для прогнозирования или поддержки решений особенно важна связь между исходными данными и фактическим результатом. Если компания не фиксирует, чем закончился процесс, модели будет не на чем учиться и нечего проверять.
Поэтому подготовка данных для ИИ начинается не с их массовой выгрузки. Сначала нужно определить, какой результат должна выдавать система, из какой информации его можно получить и как мы поймём, что результат верен.
Пять признаков, что данные подходят для первой проверки
Для запуска прототипа не требуется идеальная корпоративная база. Но у данных должно быть несколько свойств, без которых эксперимент быстро превращается в угадывание.
- Данные относятся к реальному процессу. Лучше взять пятьдесят настоящих обращений с ошибками и исключениями, чем тысячу аккуратных демонстрационных примеров. Прототип должен встретиться с той же реальностью, в которой ему предстоит работать.
- Можно определить правильный результат. Для документа это могут быть верно извлечённые поля и найденные расхождения, для звонка — согласованная оценка качества, для внутреннего ассистента — ответ со ссылкой на действующий источник. Если эксперты компании не могут договориться, что считать правильным результатом, оценить ИИ тоже не получится.
- В выборке есть сложные и пограничные случаи. Необходимы неполные документы, противоречивые источники, редкие форматы и обращения, требующие уточнения. Именно такие примеры показывают, где система должна остановиться и передать задачу человеку.
- Понятно происхождение данных и разрешённый способ их использования. До начала работы нужно определить, содержат ли материалы персональные, коммерческие или иные чувствительные сведения. Иногда достаточно обезличивания, иногда требуется закрытый контур, а часть данных использовать нельзя вовсе.
- У данных есть владелец. Кто-то должен подтвердить актуальность источников, объяснить исключения и принять решение при споре. Без такого человека техническая команда будет исправлять не систему, а собственные догадки о бизнес-процессе.
Если хотя бы часть этих условий выполняется, гипотезу обычно уже можно проверять. Не нужно ждать завершения многолетней программы управления данными, но и загружать случайный архив в модель тоже не стоит.
Почему для RAG недостаточно загрузить документы в векторную базу
Корпоративный ассистент часто строится по схеме RAG: система сначала ищет подходящие фрагменты во внутренних источниках, а затем передаёт найденный контекст языковой модели. На схеме всё выглядит довольно просто, но качество ответа зависит как минимум от двух разных этапов.
Сначала нужно проверить, нашла ли система правильный документ и нужный фрагмент. Затем необходимо убедиться, что модель корректно использовала найденную информацию и не добавила к ней собственные предположения.
Если в базе лежат старые регламенты, дубли, документы без дат и плохо распознанные PDF, более сильная модель проблему не решит. Microsoft прямо указывает, что качество RAG зависит от подготовки контента, разбиения документов, метаданных и настройки поиска (Azure AI Search).
Отдельно нужно проверять сам поиск и итоговый ответ. В инструментах оценки Microsoft эти части также разделены: retrieval показывает, насколько хорошо система находит релевантные материалы, а groundedness и completeness помогают оценить, опирается ли ответ на полученный контекст и не упускает ли существенную информацию (Microsoft Foundry).
Это важное различие для бизнеса. Когда ассистент отвечает неправильно, причиной может быть не «галлюцинация модели», а старый документ, неудачное распознавание таблицы или поиск, который вернул не тот раздел.
Не нужно сначала очищать все данные компании
Иногда подготовку к внедрению ИИ начинают с идеи привести в порядок все корпоративные данные. Создаётся большая программа, обсуждается единое хранилище, назначаются рабочие группы, а исходная бизнес-задача постепенно исчезает из поля зрения.
Я бы начинал с другого. Нужно выбрать один процесс, собрать небольшую выборку реальных примеров и посмотреть, какие проблемы данных действительно мешают получить результат.
Для проверки задачи часто достаточно 20–50 примеров, если они отражают основные варианты и разобраны вместе с владельцем процесса. Это не объём для обучения собственной модели и не основание для промышленного запуска, но вполне рабочий материал для первичной диагностики.
На этой выборке быстро становится видно, что именно придётся исправлять. Где-то не хватает метаданных, где-то OCR теряет таблицы, где-то сотрудники используют разные названия одной категории, а иногда выясняется, что необходимая информация вообще не фиксируется.
Такой результат полезнее абстрактного заключения о «низком качестве данных». Он показывает конкретный разрыв между текущим процессом и системой, которую компания хочет построить.
Как мы проверяем данные в Hyperfast Presale
В Daturum мы начинаем с небольшого набора обезличенных примеров и вместе с владельцем процесса определяем, какой результат должен считаться правильным. Затем собираем прототип, проверяем его на типовых и сложных случаях и показываем, каких данных, правил или интеграций не хватает для рабочего решения.
Что проверять на прототипе
Оценивать ИИ одной общей «точностью» опасно. У задачи может быть несколько типов ошибок, и их стоимость для бизнеса будет совершенно разной.
При обработке документов отдельно проверяют распознавание реквизитов, сопоставление сущностей и обнаружение расхождений. Ошибка в необязательном комментарии и неверно прочитанная сумма договора не должны попадать в одну статистику.
Для внутреннего ассистента важно оценить, нашёл ли он правильный источник, сослался ли на него, не смешал ли разные редакции и умеет ли отказаться от ответа при недостатке информации. Для анализа обращений также имеет значение, насколько стабильно система распознаёт редкие, но критичные категории.
Часть проверки обязательно выполняют специалисты компании. Они помогают сформировать эталонные ответы, разбирают спорные случаи и определяют, какие ошибки допустимы, а какие требуют обязательной передачи человеку.
В результате прототип должен ответить не только на вопрос «может ли модель выполнить задачу». Он должен показать, есть ли у компании достаточные данные, можно ли измерить качество и какой контур контроля потребуется при внедрении.
Хорошие данные начинаются с понятного процесса
Для первого ИИ-проекта не нужны идеальные данные. Нужен ограниченный процесс, доступ к реальным примерам, понятный правильный результат и человек, который способен объяснить, почему этот результат считается правильным.
Если этого нет, смена модели редко помогает. Если это есть, даже небольшая выборка позволяет быстро проверить гипотезу, увидеть ограничения и решить, стоит ли переходить к внедрению.
В Daturum мы проводим такую проверку до большого проекта: разбираем процесс, смотрим реальные обезличенные данные и собираем прототип. По итогам можно понять, где ИИ даст практический эффект, какие данные необходимо подготовить и имеет ли смысл двигаться дальше.