Почему AI-проект начинается с данных

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

Модель не устраняет противоречия в данных — она их усиливает и делает убедительными. Там, где отчёт показал бы две несходящиеся цифры и вызвал вопросы, языковая модель выберет одну и объяснит её связным текстом. Это хуже, чем ошибка: ошибка заметна, а уверенный неверный ответ — нет.

1. Доступность

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

2. Непротиворечивость

Одна сущность — одно определение. Пока «выручка» в отчётности и в CRM считается по-разному и нигде не написано, чем именно, любой ответ модели будет спорным. Начинать стоит не с полного словаря, а с двух десятков ключевых показателей, вокруг которых идут решения.

3. Происхождение

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

4. Разграничение

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

5. Свежесть

У каждого набора есть допустимое отставание, и пользователь должен его понимать. Ответ на данных недельной давности не ошибочен — он опасен ровно тогда, когда об этом не сказано.

Большинство корпоративных AI-сценариев работает не с таблицами, а с документами: регламентами, договорами, протоколами, перепиской. Здесь свои требования, и привычные практики хранилищ не переносятся напрямую.

• Нарезка. Документ разбивается на фрагменты. Слишком мелкие теряют контекст, слишком крупные размывают поиск. Разбиение по смысловым разделам почти всегда лучше разбиения по числу символов.
• Метаданные фрагмента. Источник, раздел, дата, версия, владелец, гриф. Без них ответ невозможно атрибутировать, а права — применить.
• Дедупликация и актуальность. В корпоративных хранилищах типична ситуация: семь версий регламента, из них действует одна. Если в индекс попали все семь, система будет уверенно цитировать отменённую.
• Разграничение на уровне фрагмента. Документ может быть общедоступен, а его приложение — нет.
• Обновление индекса. Нужен процесс: как изменения в источнике доезжают до индекса и за какое время. Разовая загрузка устаревает за недели.
• Качество распознавания. Сканы и PDF без текстового слоя дают мусор на входе; это отдельная работа, которую нельзя пропустить.

Инженерная часть этой работы — Enterprise RAG. Проверять гипотезы дешевле на ограниченном контуре: RAG-пилот по одной реальной базе знаний показывает и качество ответов, и состояние документов.

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

• Шаг 1. Выбрать сценарий с измеримой ценностью. Не «внедрить AI», а «сократить время подготовки ответа на запрос клиента». Инвентаризация сценариев и уже используемого в компании AI — AI-discovery.
• Шаг 2. Разобрать данные только этого сценария. Какие источники, какое качество, какие права, какое допустимое отставание. Объём работы становится обозримым.
• Шаг 3. Закрыть найденные разрывы. Обычно это два-три справочника, одно определение показателя и один процесс обновления.
• Шаг 4. Пилот на реальных данных, а не на выгрузке. Только так проверяется то, что действительно ломается.
• Шаг 5. Промышленный контур. Сценарий переносится в общую платформу — Restart AI Enterprise Platform, — и следующий сценарий стартует уже на готовом фундаменте.

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

• Известен перечень источников, релевантных сценарию, и способ программного доступа к каждому.
• Для ключевых показателей есть согласованные определения, зафиксированные письменно.
• Справочники сведены: одна сущность не существует под четырьмя идентификаторами.
• Прослеживается происхождение значений до системы-источника.
• Для каждого набора известно допустимое отставание, и оно видно пользователю.
• Права описаны как свойство данных, а не настройка отдельного приложения.
• Для документов: определены правила нарезки, состав метаданных и процесс обновления индекса.
• Из индекса исключены недействующие версии документов.
• Сканы и PDF без текстового слоя обработаны или исключены осознанно.
• Определено, какие данные вообще нельзя отправлять в модель, и это ограничение применяется технически.
• Есть регулярные проверки качества, а не разовая чистка перед пилотом.