Представьте, что все документы вашей компании — контракты, аналитические записки, расшифровки звонков поддержки, многопудовые сканы — вы вывалили в один «умный системный ящик» как есть. Что, по-вашему, он с ними сделает? Люди, которые это уже проходили, отвечают честно: либо он вообще откажется их принимать, либо примет, но станет отвечать невпопад, либо счёт незаметно поползёт вверх.
Komprise регулярно находит в корпоративном хранилище одну и ту же картину: от 60 до 70 процентов данных на основном, дорогом сетевом хранилище никто не трогал дольше 90 дней. McKinsey переводит это в человеческий масштаб — работники умственного труда тратят почти 19 процентов рабочей недели, около полутора часов в день, только на то, чтобы найти и собрать нужную информацию. Asana добавляет свой штраф за прерывания: после сбоя внимания требуется примерно 23 минуты, чтобы вернуться в рабочее состояние, а между приложениями человек переключается около 35 раз за день. Плохо обработанные документы едят не только диск. Они тихо умножают цену каждого прерывания.
Новичок подходит к этой «задаче» обычно с двух сторон: ищет инструмент, который уменьшит файлы, или быстрее ставит векторную базу, чтобы из кучи можно было что-то вытащить. Те, кто строил работающие системы, отсюда не начинают.
Они задают другой вопрос. Не «какой инструмент», а «зачем этим данным вообще меняться». Чтобы сэкономить место? Чтобы вложение прошло по почте? Чтобы модель тратила меньше токенов, отвечая по ним? Или чтобы сохранить архив, который обязан прожить десять лет без изменений ради соблюдения требований? Одна и та же куча под разные цели требует совершенно разного обращения. Человек, понимающий местность, сначала прибивает ограничения, прежде чем тронуть хоть что-то, — вместо того чтобы сделать «сжать» или «поставить векторный индекс» дефолтным рефлексом.
Когда ограничения зафиксированы, второй шаг — раскидать кучу по тому, чем она на самом деле является. Подписанный контракт в PDF с красной печатью, инженерный скан в 4K и двухсотстраничный регуляторный отчёт — это три разных существа. Контракту нужны структура и печать, сохранённые побуквенно. Скан набит избыточными пикселями. Отчёт несёт повторяющиеся элементы вёрстки. Прогнать все три через одну «сжать по умолчанию» — значит получить худшее из возможного: то, что должно было остаться резким, плывёт, а то, что должно было уменьшиться, упирается. Именно тут расходятся любитель и профессионал. Любитель смотрит, «на сколько уменьшилось». Профессионал — «что ни в коем случае нельзя трогать».
Спустившись на уровень глубже, профессионал возвращается к самой информации. Почему файл большой? Скан велик, потому что это плотная растровая сетка, набитая избыточностью, которую глаз не отличит, а байты — да. Текстовый документ велик из-за повторяющейся структуры и встроенных объектов. Значит, сжимать ли и как — не должно следовать за пресетом по умолчанию, а должно следовать за тем, для чего файл существует. То, что ляжет десятилетним юридическим артефактом, идёт по безвозвратному, обратимому пути. То, что смотрят на экране или запихивают в письмо, — по сжатию с потерями, но с сохранением сути. Забрать переключатель «без потерь или с потерями» из рук дефолта — вот та черта, где профессионал и заводское поведение инструмента расходятся.
Ошибёшься с типом — рухнет всё, что ниже. Отметишь контракт как «с потерями», печать смажется — это инцидент. Заставишь скан, которому положено с потерями, остаться без потерь — размер не сдвинется, а весь конвейер затормозит. Поэтому профессионал предпочтёт потратить десять минут в начале на вопрос «в какую корзину это кладём и кто им потом пользуется», чем расхлёбывать аварию потом. Типизация — не формальность в процессе. Это фундамент, на котором стоит всё остальное.
Маленький пример. Сканированный контракт держится на печати и дате подписания — смажь их, и юридически вы изменили документ. Медицинский снимок: сожмёшь не тот край — и скроешь как раз то, что важно. Любитель видит «на шестьдесят процентов меньше» и радуется. Профессионал спрашивает: «а нет ли в этих шестидесяти процентах того, что трогать нельзя». Перед сжатием профессионал выясняет, кто пострадает, если эта штука «изменится». Ответ и решает, сжимать ли вообще и как именно.
Есть ещё один слой, который новички упускают: один и тот же документ часто живёт в нескольких системах с несовпадающими версиями. Профессионал сначала приводит в порядок дубликаты и версии, и только потом говорит о сжатии и поиске — потому что строить индекс на грязных данных гарантирует плохой поиск, что бы вы ни делали дальше. И затраты надо считать целиком: эмбеддинги посчитаны однажды, переранжирование прогнано однажды, модель прочитала один раз — где токены покупают больше всего ценности, вытягивать ли лишние куски, чтобы модель сама выбрала, или сначала отобрать и взять меньше? Пока эта арифметика не ясна, «экономия» — просто лозунг. Особенно в связке извлечения с генерацией: каждый вытащенный фрагмент модель читает заново, так что грязные документы и небрежная нарезка накапливаются в счёте за токены ежемесячно, как сложный процент. Сжать сначала, прибрать сначала — зачастую дешевле, чем покупать потом более крупную модель.
Люди, которые это запускали, относятся к базе знаний как к живой системе, а не к одноразовой загрузке. Документы меняются, бизнес меняется, то, что отвечает верно сегодня, может споткнуться, когда придёт версия следующего месяца. Поэтому они с самого начала оставляют место для оценочного набора и отката, считая «построить» и «обслуживать» одной работой. Этим и объясняется, почему столько демо ослепляет, а в продакшене рассыпается: демо доказывает, что система может что-то вернуть; продакшен требует, чтобы она продолжала отвечать верно на реальных, грязных, меняющихся документах. Тот, кто видит в «вернул что-то» финиш, и тот, кто видит в этом старт, строят совершенно разные системы.
Многие считают, что сжатие и поиск — две отдельные работы. Профессионал — нет. Он видит «прибрать → уменьшить → нарезать → перевести в вектор → найти → ответить» как одну линию и доверяет только результату всей линии, а не ни одному красивому числу по отдельности. А перед сжатием и поиском обычно стоит ещё шаг уборки — одни и те же материалы разбросаны по дюжине папок с хаотичными именами. Профессионал сначала решает, куда это положить и по какой оси классифицировать, потому что даже качественный поиск не спасёт документ, положенный не туда. Чисто сжатый документ несёт меньше шума в поиск, тратит меньше токенов, держит стабильнее выдачу — сжатие здесь не бесплатное приложение к экономии места, а предварительная стадия качества поиска. И когда поиск упорно отвечает невпопад, профессионал не винит сразу модель; он идёт назад и спрашивает: а не разрубил ли кусок предложение пополам, а не тонет ли разговорный вопрос в буквальном совпадении, а не обрезан ли нужный фрагмент.
На этапе поиска инструментарий профессионала выглядит не так, как представляет любитель. Он не бросает в систему сырой вопрос. Реальные пользователи спрашивают сленгом, сокращениями, синонимами и часто упаковывают три намерения в одно предложение — той чистой фразы «опишите политику возврата», что есть в оценочных наборах, в жизни почти не бывает. Поэтому они делают гибридный поиск: ключевой путь хватает точные совпадения, семантический векторный ловит близость смысла, два пути сливаются, и доля пропусков сразу падает. После начального прогона переранжировщик выталкивает по-настоящему релевантное наверх. Для сложных вопросов один разговорный запрос переписывают в несколько удобных для поиска подзапросов, ищут каждый и собирают вместе. Права и источники фильтруют заранее, чтобы ничего лишнего не вылезло наружу.
Ни один из этих ходов не ради красоты. Все они бьют в одну точку: превратить «отвечает верно» из удачи в измеряемый показатель. Это как раз то, что никто не просит, но профессионал обязательно делает — подготовить прежде чем писать код пачку размеченных пар вопрос-ответ с указанием истинного источника, потому что без этого у «верно» нет определения; разложить долю пропусков и долю ответов невпопад по типам вопросов, чтобы сразу видеть, какой класс постоянно падает; прогнать старый оценочный набор заново после каждого обновления базы, чтобы перехватить тихую деградацию «сегодня верно, через месяц неверно».
Так почему этому верить? Не потому, что вендор говорит «мы точны», и не потому, что покупатель надеется «должно хватить». Устоит то, что третья сторона тоже может воспроизвести: независимо размеченный золотой набор вопросов, где любой, прогнав вашу систему на тех же метках, увидит recall@k и достоверность на столе; слепые тесты, где новый и старый конвейеры отвечают на реальные вопросы анонимно, под независимой оценкой, и разрыв не опирается на «мы тестировали внутри»; и набор регрессионных тестов, где случаи, известные как верные, обязаны оставаться верными, с открытым красно-зелёным статусом. То же самое и к сжатию: открывается ли сжатый документ точно как прежде, на месте ли печать, не уехала ли вёрстка — откройте и сравните с оригиналом. После уменьшения сколько токенов реально убавилось и держит ли поиск — прогоните задачу ниже по цепочке, и ответ будет. Корректность не приходит из чьего-то обещания. Она приходит из действий, которые любой может проверить.
Мы в UglyPear Data недавно сделали небольшой шаг на стыке сжатия и поиска: адаптировали предварительное сжатие документов перед извлечением так, чтобы оно устойчиво работало на нескольких основных больших моделях, — и один и тот же похудевший документ разные модели могли стабильно прочитать и использовать. Этот шаг бьёт прямо в тот порог, о котором шла речь выше: уменьшить, но не превратить в нечитаемое для модели. До полной инженерной глубины тут далеко, но направление верное — сначала сварить «маленькое» и «читаемое» в одну вещь, а потом наращивать оценку, переранжирование и наблюдаемость. Подход UglyPear Data к связке сжатия и семантического поиска в режиме приватного развёртывания, когда данные не покидают контур, описан на https://www.uglypear.com/ru/products/.
В конечном счёте вся эта картина — не список функций продукта, а привычка: сначала спросить, зачем, а потом решать, как; сначала определить «верно», прежде чем говорить о «быстро» и «дёшево»; и доказывать, что оно и правда верно, действиями, которые любой воспроизведёт, а не красивыми лозунгами. Как строить такую линию с упором на суверенитет данных и локальное размещение без выхода в публичные сети, разбираем в блоге UglyPear Data: https://www.uglypear.com/ru/blog/. Там же — заметки о том, почему воздушно изолированные контуры и локально-ориентированная обработка меняют требования к сжатию документов, когда речь заходит о соблюдении границ хранения.
Ниже — таблица того, чем заводское поведение инструмента отличается от того, как ведёт себя человек, запускавший такое в продакшене, в нескольких решающих точках.
| Решающая точка | Поведение инструмента по умолчанию | Как ведёт себя опытный исполнитель |
|---|---|---|
| Точка отсчёта | Сжать напрямую / сразу поставить векторный индекс | Сначала фиксирует, зачем данным меняться |
| Обработка документов | Одно сжатие по умолчанию на всё | Делит по контрактам / сканам / отчётам, затем выбирает |
| Без потерь или с потерями | Следует за пресетом | Решает по назначению: архив — без потерь, предпросмотр — с потерями |
| Сжатие против поиска | Считаются двумя работами | Одна линия, доверие только результату всей линии |
| Запрос | Поиск сырым предложением | Гибридный поиск + переранжирование + перепись и разбор |
| Доказательство качества | Собственное заявление вендора | Размеченный золотой набор + слепой A/B + набор регрессий |
Попробовать сейчас
Чтобы увидеть подход, который сплетает «приватное развёртывание, данные не покидают контур, сжатие и семантический поиск» в одну производственную линию, загляните сюда:
Частые вопросы
Вопрос: У нас небольшая компания, документов немного. Разве сжатия по умолчанию недостаточно?
Ответ: Зависит от того, что документы должны делать. Передать файл внутри команды — дефолтного сжатия обычно хватает. Но стоит документам пойти в поиск, в модель или стать доказательством, разница от типизации и выбора стратегии становится ощутимой.
Вопрос: Может ли сжатый документ всё ещё служить юридическим доказательством?
Ответ: Зависит от метода. Архивный класс идёт без потерь и обратим, содержимое и печати не тронуты — и этого достаточно. Предпросмотр с потерями годится только для быстрого просмотра. Ключ не в том, «сжимали ли», а в том, «по какому пути пошёл этот тип».
Вопрос: Гибридный поиск звучит сложно. Потянет ли его небольшая команда?
Ответ: В ядре это «ключевые слова плюс семантика», слитые вместе, а затем переранжировщик — и то, и другое имеет открытые реализации. Порог не в деньгах, а в готовности считать «отвечает верно» вещью, которую измеряют постоянно.
Вопрос: Как понять, что база знаний и правда отвечает верно?
Ответ: Не верьте демо. Нужен размеченный стандартный набор вопросов и ответов, воспроизводимая оценка, плюс слепое тестирование и регрессии. Если третья сторона может прогнать вашу систему на том же стандарте, вывод устойчив.
Вопрос: Сжатие и связка извлечения с генерацией обязаны делаться вместе?
Ответ: Не обязательно одним исполнителем, но видеть их надо как одну линию. Чисто сжатый документ, попадая в поиск, несёт меньше шума, тратит меньше токенов и держит выдачу стабильнее — разрыв двух работ обычно бьёт по обоим концам.