Как подготовить данные для корпоративного ИИ

На практике проблемы часто начинаются значительно раньше. ИИ может быть подключён к современной модели, иметь хорошую инфраструктуру и правильно настроенный поиск — и всё равно давать неудовлетворительный результат. Причина может находиться в самих данных.

Поэтому подготовка данных для корпоративного ИИ — это не просто загрузка файлов в базу.

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

В каждом случае набор необходимых данных отличается.

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

Поэтому первый этап — не загрузка документов.

Первый этап — определение бизнес-сценария и результата, который должен выдавать ИИ.

И это уже принципиальный момент.

Файл Инструкция_финал.pdf и запись в ERP — это не просто два разных формата данных. Это два разных типа источников с разными правилами доверия и обновления.

Это уже не проблема нейросети.

Это проблема управления корпоративными знаниями.

Количество документов само по себе не является качеством базы знаний. Иногда из 40 000 файлов для конкретного сценария реально нужны 3 000. А иногда — 300.

ИИ получает пять документов. Но это не пять независимых источников.

Это может быть один документ, размноженный по корпоративной инфраструктуре.

Если оба документа попадут в систему без метаданных, ИИ увидит два похожих фрагмента информации.

Откуда ему знать, какой использовать?

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

В некоторых системах потребуется значительно больше.

И только после этого искать по содержанию.

Это принципиально меняет качество результата.

Хороший корпоративный поиск использует не только смысл текста, но и контекст источника.

Можно экспортировать всё в CSV и передать модели. Но при таком подходе легко потерять смысл связей.

Это не просто набор строк.

Это структурированная предметная модель.

Поэтому не каждый источник нужно превращать в документы для RAG.

Это одна из ключевых архитектурных границ корпоративного ИИ.

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

Поэтому корпоративный ИИ должен понимать, где находится знание, а где — текущее состояние бизнеса.

Значение цены может отличаться.

Название может отличаться.

Артикул может быть записан по-разному.

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

Для ключевых сущностей необходимо определить источник истины.

Тогда архитектура ИИ использует данные осознанно.

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

Поэтому полезно формировать корпоративный словарь терминов.

Если всё собрать в единую базу знаний без учёта прав, появляется серьёзная проблема.

А система потенциально может найти документ, доступный только руководству.

недостаточна для корпоративной среды.

При этом важно учитывать не только права пользователя в интерфейсе ИИ.

Если сотрудник имеет доступ к CRM, но не имеет доступа к финансовой системе, ИИ не должен создавать обходной путь к финансовым данным.

ИИ не должен становиться универсальным каналом доступа ко всей корпоративной информации.

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

А иногда — вообще не подключать определённый источник к конкретному сценарию.

Не вся информация компании должна становиться доступной корпоративному ИИ.

Для общего текста ошибка может быть незначительной.

Для технической документации она может полностью изменить смысл.

Поэтому документы после OCR нельзя считать автоматически качественными.

Особенно осторожно нужно работать с чертежами, схемами, техническими таблицами и сканами низкого качества.

Связи между колонками становятся менее очевидными.

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

Поэтому при подготовке данных нужно учитывать структуру документа, а не только его текст.

If you cut it in the middle of a paragraph, you can separate the rule from its exception. Получится:

При поиске система может получить только первый фрагмент.

Ответ окажется формально похожим на правильный, но неполным.

Поэтому границы фрагментов должны учитывать смысловую структуру документа.

Это уже контекст.

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

Если источник невозможно определить, доверие к ответу существенно снижается.

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

Это уже напоминает не просто работу с файлами, а управление жизненным циклом знаний.

Это намного полезнее для бизнеса, чем система, которая отвечает на всё.

Корпоративный ИИ должен быть ограничен качеством и областью своих источников.

На самом деле процесс значительно шире:

И это ещё не конец.

После запуска данные продолжают меняться.

Поэтому система должна уметь обновляться.

Поэтому нужны тестовые вопросы.

Затем система проверяется на этих сценариях.

Так появляется измеримое качество.

Но для корпоративной системы не менее важно:

«Не показал ли ИИ то, чего показывать не должен?»

Такие тесты помогают проверить безопасность и управляемость системы, а не только её «умность».

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

Тогда новые ИИ-сценарии смогут использовать уже подготовленную основу.

Поэтому при проектировании нужно разделять:

статические знания и операционные данные.

Это одна из фундаментальных границ корпоративного ИИ.

Поэтому выбор модели и инфраструктуры должен происходить после анализа данных, а не до него.

Это гораздо полезнее, чем критерий:

«Мы собрали все документы в одну папку».

Это уже гораздо ближе к машинно-обрабатываемому корпоративному знанию.

Но только бизнес обычно может сказать:

Поэтому подготовка данных — это не исключительно IT-задача.

Без участия владельцев бизнеса можно идеально обработать технически неправильную информацию.

Это не обязательно должны быть пять разных сотрудников.

Но сами зоны ответственности должны существовать.

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

Когда говорят: «Нам нужно обучить ИИ на всех документах компании», сразу возникает вопрос: Зачем?

Для большого количества прикладных задач не требуется переобучать базовую модель на корпоративных документах.

В таком сценарии ценность создаёт не само «обучение на документах», а правильно спроектированный контур работы с корпоративными знаниями.

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

Модель в этом случае может работать именно так, как от неё требуется.

Проблема находится выше по цепочке.

Даже идеально подготовленная база не отменяет:

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

Если любой элемент слабый, результат может быть неудовлетворительным.

Но если система не знает:

• - какой документ актуален;
• - какой источник является главным;
• - кому можно показать информацию;
• - где находится нужное значение;
• - как отличить архив от действующего регламента;
• - какие данные нужно получать напрямую из ERP;
• - когда следует отказаться от ответа;

то мощность модели не решит архитектурную проблему.

Поэтому подготовка данных — это не предварительная уборка перед «настоящим ИИ».

Это часть самого ИИ-проекта.

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

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

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