В прошлом месяце я слушал, как знакомый, отвечающий в компании за управление знаниями, рассказывал историю, которая его прямо-таки доконала. Компания вложилась в корпоративную систему вопрос-ответ: десятки тысяч PDF, файлов Word и сканов разом залили в векторное хранилище, и все ждали, что сотрудник спросит — и тут же получит ответ. Не дождались. Сканы вошли в базу размытыми, поиск выдавал абзацы, не имеющие к вопросу никакого отношения, а в финансовом отделе кто-то успел вставить контракт с данными клиентов прямо в общедоступный чат-бот. Вывод рабочей группы получился одновременно смешным и грустным: модель в порядке — то, чем её кормят, нет.
История типовая. Прикиньте обычный рабочий день: сотрудник переключается между 35 разными приложениями. Исследования концентрации внимания дают ещё одну цифру: после того как задачу прервали, человеку в среднем требуется 23 минуты, чтобы снова войти в рабочий ритм. Поиск ответа и без того стоит дорого; если корпоративная система вопрос-ответ к тому же промахивается, люди молча возвращаются к папкам на общем диске — или, что хуже, вставляют документы в посторонние AI-инструменты, создавая себе новый риск на пустом месте.
Поэтому говорить сегодня буду не о том, какая модель лучше, а о дороге перед моделью: как превратить документы в данные, которые модель действительно способна «переварить». У UglyPear Data для этого этапа есть отдельный продукт — база инженерии данных RAG. Формула короткая: высокопроизводительное сжатие документов в связке с инженерией данных для RAG, развёртывание полностью приватное, данные не покидают внутреннюю сеть.
Что ломается, если скормить документы модели напрямую
Многие представляют RAG как «нарезали документ на куски, посчитали векторы, сложили в хранилище». Но стоит запустить систему на живом материале, как выясняется: корпоративные документы — не тот аккуратный текст, который рисуется в воображении.
Первый слой проблем — форматы. Внутри PDF соседствуют сканы, среди файлов попадаются OFD — формат жёсткой вёрстки, распространённый на китайском рынке, таблицы прячутся в картинках, а печать накрывает ключевые реквизиты. Нарежешь такой материал без обработки — получишь обрывки, которые модель не в состоянии прочитать; поиск от этого плывёт, и предсказать, куда именно, невозможно.
Второй слой — дубли. Один контракт в пяти версиях, протоколы совещаний, скопированные по восемь раз, презентации, наполовину состоящие из шаблонных слайдов. Повторы, попав в векторное хранилище, не только съедают место, но и мутят результаты выдачи: задаёшь один вопрос — получаешь пять почти одинаковых пассажей, а настоящий ответ оказывается вытеснен куда-то в конец списка.
Третий слой — чувствительные данные. Номер паспорта в договоре, банковский счёт в отчётности, домашний адрес в резюме: стоит этим полям проследовать за документом в поисковую цепочку, как их увидит любой, кто спросит. Если же вопрос задан в общедоступном инструменте, клиентские данные уходят из компании окончательно.
Сложите три слоя вместе — и станет ясно, почему большинство «проектов вопрос-ответ по документам» теряют пользователей на третьем месяце после запуска.
Теневой ИИ: риск, который никуда не деться
Здесь стоит задержаться на теме общедоступных инструментов. В отчёте IBM «Cost of a Data Breach» за 2025 год есть показательная цифра: одна из пяти компаний сталкивалась с утечкой, спровоцированной тем, что сотрудники пользовались AI-инструментами в обход установленных правил — в отрасли это явление окрестили «теневым ИИ». Средняя стоимость утечки у таких компаний оказывается на 670 000 долларов выше, чем у коллег по рынку. Ещё интереснее другая цифра: среди организаций, переживших утечку, 63% до сих пор работают без письменной политики управления AI.
Если по-человечески: запрещать менее эффективно, чем организовать нормальный путь. Люди идут в сторонние AI-инструменты не с целью слить секреты — они просто не получают внятного ответа из официальных каналов. Вместо очередного запрета логичнее починить внутренний конвейер: документы локально очищаются, обезличиваются и сжимаются, и только после этого попадают в поисковую базу. Сотрудник получает надёжный ответ внутри корпоративной системы — и вставлять контракт в чужое окно чата ему попросту незачем.
Возникнет резонный вопрос: нельзя ли просто купить готовую SaaS-базу знаний? Можно, но держите в голове одну деталь: после загрузки документы живут на чужих серверах. Для многих отраслей это не принципиально; для финансов, медицины, юриспруденции и государственных структур контракты, медицинские карты и материалы дел — красная линия, которую пересекать нельзя. Смысл приватного развёртывания вовсе не в технической моде, а в том, что решение о судьбе данных остаётся в ваших руках. UglyPear Data закладывает принцип «данные не покидают внутреннюю сеть» как отправную точку: база инженерии данных RAG разворачивается полностью приватно, 13 категорий чувствительной информации, характерной для AI-сценариев, обнаруживаются и обезличиваются автоматически, и весь цикл отрабатывается в среде самой компании. Что стоит за этими 13 категориями? Помимо привычных полей — удостоверение личности, банковская карта, номер телефона — туда входят и отраслевые структуры, полезные в финансовых, медицинских и юридических сценариях. Насколько правила обезличивания ложатся на конкретный бизнес, честнее проверить на собственных реальных документах.
Формулировка «шесть этапов обработки плюс восемь возможностей» звучит как маркетинговый слоган, но при разборе оказывается будничной. Этапы — это шаги между приёмкой документа и его загрузкой в базу. Возможности — базовые операции вроде сжатия, обезличивания и структурирования, которые переиспользуются на разных шагах. Как именно спроектирован каждый этап, лучше всего посмотреть в официальных материалах и прогнать по собственному документопотоку — это понятнее любых пересказов.
Сначала сжать, потом загрузить: экономия в буквальном смысле денежная
У инженерии данных есть и вторая сторона — затратная. Основную массу в корпоративных архивах, как правило, набирают сканы и изображения: сканированный контракт на несколько сотен страниц легко весит сотни мегабайт. Заливать такой материал в базу как есть — значит переплачивать и за хранение, и за векторизацию.
Вот здесь и проявляется ценность сжатия. Движок сжатия SmartSlim охватывает 8 типов форматов — PDF, изображения, видео, аудио, Office, OFD, сканы и другие, — а размер файла способен уменьшить на 60–80%, причём вся обработка идёт на самой машине. Для сценариев с большими языковыми моделями оптимизация ещё важнее: по измерениям на базе GPT-4o стоимость токенов для картинок снижается на 85,9%. Документы стали меньше и чище — и на каждом шаге конвейера, от эмбеддинга до поиска и ответа, расход падает следом. Один крайний случай из официальных тестов: 443-страничный OFD-документ был обработан от начала до конца за 124 секунды, с сохранением и печати, и вёрстки.
Это же отвечает на частый вопрос: не портит ли сжатие содержимое? Режим сохранения точности не трогает лежащую в основе структуру вёрстки и оптимизирует только избыточные данные, так что сам текст не страдает. И всё же полистать несколько ключевых страниц перед загрузкой — привычка, которую я бы сохранил.
Три пути к большой модели: как выбрать
Соберём сказанное в одну таблицу. У корпоративных документов, добирающихся до большой модели, в общем-то три дороги:
| Критерий | Вставить напрямую в общедоступный AI-инструмент | Своя векторная база с нарезкой «в лоб» | Сначала база инженерии данных RAG, потом загрузка |
|---|---|---|---|
| Уходят ли данные из внутренней сети | Уходят, и их дальнейший след не контролируется | Не уходят (при условии собственного развёртывания) | Не уходят, полностью приватная среда |
| Работа с чувствительной информацией | Никакой обработки, всё видно как есть | Модуль обезличивания придётся разрабатывать самим | Автоматическое обнаружение и обезличивание 13 категорий |
| Сканы и файлы с жёсткой вёрсткой | Практически непригодны | Качество после нарезки низкое, поиск сбивается | Сжатие с сохранением точности, печать и вёрстка остаются на месте |
| Объём в базе и стоимость запросов | Понятия «база» нет, вставка каждый раз вручную | Исходный объём целиком, накладные расходы высоки | Объём меньше на 60–80%, экономия токенов на картинках 85,9% (по GPT-4o) |
| Развёртывание и сопровождение | Ноль настройки, все риски на вас | Весь конвейер инструментов строится своими силами | Шесть этапов и восемь возможностей из коробки |
| Кому подходит | Для разовых личных справок | Сильная команда разработки и нечувствительные данные | Командам с требованиями к соблюдению норм и к затратам |
Оговорка для честности: это рамка для выбора, а не сравнительное тестирование продуктов. Состав документов у каждой компании свой, и расставлять приоритеты придётся самостоятельно — медицина поставит обезличивание на первое место, электронная торговля, возможно, будет считать деньги.
Регуляторы тоже подталкивают
Есть и внешняя переменная. В мае 2025 года Министерство финансов Китая совместно с восемью другими ведомствами выпустило «Уведомление о содействии применению стандарта учётных данных электронных ваучеров» (Cai Kuai [2025] No. 9): бухгалтерское программное обеспечение организаций должно быть обновлено и адаптировано к стандарту учётных данных электронных ваучеров до 31 декабря 2027 года. Переведём на человеческий язык: движение корпоративных документов к структурированному, машинночитаемому виду прописано в расписании, начертанном политикой, — а не оставлено на усмотрение.
Полностью цифровые электронные счета-фактуры уже действуют по всей стране с покрытием выше 80%, а корректный формат для报销 архивации — структурированный XML-файл с цифровой подписью. Отсюда простой вывод: в ближайшие годы вопрос инженерии документных данных для компании — не «делать или нет», а «в каком темпе делать». Кто раньше выстроит цепочку «очистка — обезличивание — структурирование — загрузка», тому проще подключать и регуляторные требования, и новые модели, и аудит. Кто отложит — будет нагонять в авральном режиме.
Страница базы инженерии данных RAG от UglyPear Data находится здесь. Возможности сжатия собраны на странице SmartSlim; а о том, как именно два продукта работают в связке, подробнее разобрано в техническом блоге.
Попробуйте сейчас
- База инженерии данных RAG (приватное развёртывание, обезличивание 13 категорий, шесть этапов + восемь возможностей): https://www.uglypear.com/ru/
- SmartSlim (движок сжатия, десктоп-версия, SDK и API): https://www.uglypear.com/ru/products/
- Технический блог UglyPear Data (практика по сжатию и инженерии данных, обновляется регулярно): https://www.uglypear.com/ru/blog/
Частые вопросы
Q: RAG-проект работает плохо — менять модель или сначала приводить данные в порядок?
A: Сначала данные. Корень большинства «ответов невпопад» лежит в качестве документов — размытые сканы, дубли, хаотичная структура. Прогоните очистку, обезличивание и сжатие, затем тестируйте заново: заметная часть проблем уйдёт сама. Порядок переворачивать не стоит: менять модель на неотлечённых данных — всё равно что перекладывать их из одного беспорядка в другой, результат будет примерно одинаковым.
Q: Все 13 категорий чувствительной информации проверяются локально?
A: Да. Обнаружение и обезличивание выполняются внутри приватной среды компании, данные не покидают внутреннюю сеть, а правила можно адаптировать под отраслевые сценарии.
Q: Не упадёт ли качество ответов, если скормить модели сжатые документы?
A: Режим сохранения точности не затрагивает базовую структуру вёрстки и оптимизирует только избыточные данные, поэтому текст не меняется; для картинок по измерениям на базе GPT-4o стоимость токенов дополнительно снижается на 85,9%. Выборочная проверка ключевых страниц перед загрузкой всё же рекомендуется.
Q: У нас уже есть собственная векторная база. Пригодится ли база инженерии данных RAG?
A: Пригодится. База отвечает за этапы до загрузки — очистку, обезличивание, сжатие и структурирование; готовый результат подключается к существующей векторной базе напрямую, ничего сносить не нужно.
Q: Насколько требовательно приватное развёртывание к оборудованию?
A: Зависит от объёма документов и числа одновременных пользователей. Разумный путь — взять партию реальных документов и провести небольшое пилотное тестирование, а затем планировать ресурсы по фактическим цифрам; это надёжнее любых прикидок на глаз.