Представьте отдел, который за пять лет накопил тысячи файлов: договоры, обращения клиентов, инструкции, отсканированные бумаги. Их свалили в одну папку и сказали большой языковой модели: «разберись сама». Она видит десятки гигабайт сырья. Находит по имени файла и по ключевым словам две-три страницы. И выдаёт ответ, в котором один контрагент превратился в другого, а срок — в прошлый квартал.
Руководитель делает естественный вывод: модель слабая, надо брать дороже и длиннее промпт. Деньги уходят, а ответ снова едет вбок.
А правда — в другом месте. База знаний отвечает невпопад не потому, что модель глупа. А потому, что слой документов, который предшествует модели, просто сломан. Менять модель — это поднимать потолок там, где ещё не построен пол.
Почему смена модели не лечит проблему
Есть скрытая модель затрат, которую легко проглядеть. Гигиена документа до попадания в базу — его объём, формат, чувствительные поля, повторяющийся мусор — напрямую задаёт потолок качества поиска. Какую бы модель вы ни поставили сверху, она упирается в грязный вход. В индустрии это называют data hygiene: прибрать «беспорядок, раздутый объём и грязь» до того, как кормить систему, почти всегда выгоднее, чем докупать вычисления потом.
Кажется, что виновата модель. Но если присмотреться, корень гораздо раньше. Суть поиска никогда не в том, «умная ли модель», а в том, может ли нужная пользователю информация быть точно локализована. Этот принцип первичен по отношению к любым модельным трюкам. Модель — лишь последний цех в конвейере. Если предыдущие цеха работают криво, последний не спасёт, сколько ни старайся.
Что на самом деле делает инженерная база
Тот, кто строит базу знаний всерьёз, не отдаёт сырые файлы модели напрямую. Сначала документ проходит через инженерную базу: его сжимают и «худеют», приводят форматы к единому виду, скрывают чувствительную информацию по правилам, режут на фрагменты, удобные для поиска, и только потом отдают вместе с указанием источника. У этого процесса есть понятная последовательность шагов — сбор, очистка, разбиение, векторизация, поиск, генерация — и каждый шаг влияет на то, каким получится ответ.
Опытные команды делают ещё то, что заказчик не просил, но что спасает проект. Например, готовят реальный набор вопросов и ответов как эталон для приёмки, вместо того чтобы говорить «вроде стало точнее на глаз». Превращают качество поиска в измеряемую метрику и регулярно прогоняют проверки: если какой-то класс вопросов откатился назад — сразу видно. Перед запуском длинной задачи заранее продумывают, как именно она может упасть и где её границы. Гибридный поиск, переранжирование, переписывание запроса, семантическое разбиение и офлайн-оценка качества фреймворками вроде RAGAS — всё это открытая инженерная практика, а не чья-то секретная формула. Сложность не в том, чтобы придумать шаг, а в том, чтобы довести каждый до воспроизводимого результата и вылизывать базу как продукт.
Слово «воспроизводимо» чаще всего остаётся лозунгом. Что реально докажет, что база работает? Не демо от вендора. А независимо размеченный золотой набор вопросов-ответов, воспроизводимые офлайн-метрики, устойчивые слепые A/B-тесты, постоянно работающий набор регрессионных проверок и обратная связь от реального использования. Без этого «стало точнее» — лишь ощущение.
Шаг вперёд: превратить препроцессинг в наблюдаемый процесс
Сделать препроцессинг документов видимым — это прогресс, который недооценивают. Несколько тысяч документов надо сжать, перекодировать форматы и загрузить в базу; процесс тянется часами. Где он застрял, какой именно файл тихо упал — традиционный конвейер просто не показывает. В недавней базе RAG-инженерии данных от UglyPear Данные этот этап сделали наблюдаемым: препроцессинг (сжатие, конвертация форматов и прочие долгие пакетные задачи) теперь виден целиком. Прогресс отображается, можно сразу понять, какой шаг замедлился или какой файл не прошёл, а при необходимости — откатить и повторить.
Что это даёт читателю? Больше никакого ожидания у чёрного экрана. И больше никакого сюрприза в конце, когда выясняется, что последние 30% документов так и не попали в базу. Вы видите, где задача идёт, и можете вмешаться до того, как весь прогон пойдёт прахом.
На вид этот шаг мелкий. Но именно он отделяет «у нас это как-то запускается» от «это можно пустить в производство и отвечать за результат».
Механика: почему эти шаги правда работают
Объяснить «почему работает» полезнее, чем просто перечислить функции.
Начнём со сжатия. Типичная картина: один договор в юридическом отделе весит сотни мегабайт, и полная загрузка рушит и хранилище, и поиск одновременно. По механике дела: в документе полно повторов, избыточных объектов и медиа, которые можно перекодировать под нужды — так объём обычно падает на 60–80%, а текст и печати, то есть критичная информация, сохраняются. Ваш выигрыш: та же поисковая база после похудения отвечает быстрее и дешевле, а большой файл перестаёт застревать на этапе «не влезает в модель».
Дальше — поиск. Искать по имени файла «договор с поставщиком за 2024 год» — значит не найти, если имя не совпало. Искать по смыслу — значит модель поймёт «с кем подписано, о чём и где пункт». Это разрыв между семантическим поиском и подбором по имени: первый видит значение, второй — лишь символы. Но семантика не вытянет грязный вход. Именно предварительная очистка и разбиение решают, на сколько процентов раскроется её потенциал.
И форма развёртывания. Самое страшное в чувствительном документе — не то, что модель ошиблась, а то, что данные покинули внутреннюю сеть. Приватное развёртывание прогоняет весь препроцессинг и поиск на ваших собственных машинах: документ не выходит за пределы корпоративной сети, и комплаенс-картина изначально чище. Это иная дорога, чем «купить модель побольше в облаке»: там вы отдаёте данные ради ума, здесь оставляете ум дома.
Отдельно про «каждое предложение с источником». Эту возможность часто считают украшением, а по факту это требование. В регулируемых отраслях ответ, который не может указать, из какого файла и с какой страницы взят, нельзя ни проверить, ни на кого-то повесить ответственность. Инженерная база ставит метку происхождения на каждый фрагмент ещё на этапе разбиения и загрузки, а при генерации выдаёт источник вместе с ответом. Заказчику это может быть «без разницы», а для специалиста — красная линия приёмки. Комплаенс, заложенный заранее, — это когда правила прописаны до того, как документ попал в базу, а не латаются после инцидента.
Есть и легко недосчитанный счёт. Цена отказа от препроцессинга не разовая, она нарастает: поиск всё неточнее, пользователи всё меньше доверяют, в итоге перестают пользоваться — и вся ранее влитая вычислительная мощность уходит в никуда. Напротив, крепкий препроцессинг на входе ставит каждый следующий ответ на более высокий пол, и предельные затраты со временем падают. Речь не о том, сколько вы сэкономите, а о том, жизнеспособен ли вообще этот путь.
Прямая закладка против препроцессинга: таблица
Сравним «бросить файл в модель» и «пропустить через базу» по измеряемым параметрам.
| Измерение | Закинуть сырые файлы в LLM | Через препроцессинг базы данных |
|---|---|---|
| Объём документов | оригинал, часто сотни МБ | после сжатия обычно −60%…−80% |
| Чувствительные данные | сырые PII / коммерческие тайны на виду | 13 категорий чувствительной информации автоматически скрываются |
| Прослеживаемость | трудно сказать, какой фрагмент процитирован | каждое предложение несёт источник, проверяемо |
| Контроль длинных задач | чёрный ящик, сбои трудно локализовать | прогресс виден, сбои локализуемы, возможен откат |
| Дружественность к разным моделям | большие файлы часто не загружаются в некоторые модели | тот же «похудевший» документ стабильно читается разными моделями |
Три набора цифр, которые говорят, почему нельзя сокращать
Почему скрытие данных нельзя опускать? В отчёте IBM за 2025 год «Cost of a Data Breach» есть неприятная цифра: среди украденных данных на долю персональных данных клиентов пришлось 53%, персональных данных сотрудников — 37%, интеллектуальной собственности — 33%. А интеллектуальная собственность — самая дорогая категория: 178 долларов за одну запись. Если база знаний отдаёт такие поля как есть, риск — уже не «возможно», а «произошло».
Есть и чисто человеческий масштаб потери. По оценке McKinsey, работники знания тратят около 19% рабочей недели на то, чтобы найти и собрать нужную информацию. Пятая часть времени уходит не на работу, а на поиск входа в неё. База, которая отвечает невпопад, удваивает эту трату: люди ищут сами, потому что системе не доверяют.
Давление со стороны хранения тоже немалое. Опрос клиентов Komprise показывает: 60–70% данных на корпоративном первичном хранилище NAS не открывались уже более 90 дней, но продолжают занимать самое дорогое место. Если база знаний не делает похудение и разделение на слои, она лишь раздувает этот ком «холодных данных» дальше.
Вернёмся к началу
База знаний отвечает невпопад — и в большинстве случаев дело не в модели, а в том, что слой документов не прошёл проверку. Прежде всего сделайте препроцессинг наблюдаемым, с возможностью отката и с удержанием данных внутри сети — и лишь потом говорите о модели. Перепутан порядок, и сколько ни лейте вычислений, толку не будет.
Попробуйте сейчас
Хотите, чтобы корпоративные документы реально работали на вас? Взгляните на направления от UglyPear Данные:
- База RAG-инженерии данных и приватное развёртывание: https://www.uglypear.com/ru/products/
- Сжатие документов и нормализация форматов: https://www.uglypear.com/ru/products/
- Организация файлов и семантический поиск: https://www.uglypear.com/ru/products/
- Инженерные практики и рекомендации по выбору: https://www.uglypear.com/ru/blog/
Частые вопросы
База отвечает невпопад — менять модель на бóльшую или править данные?
В большинстве случаев проблема в данных. Какая бы модель ни стояла, она упирается в потолок, заданный качеством входа. Сначала приведите в порядок сжатие, очистку, разбиение и скрытие чувствительного — и потолок качества поиска поднимется. Смена модели обычно отвечает за «достаточно ли высок потолок», а инженерная база — за то, «достаточно ли устойчив пол».
Не сотрёт ли сжатие печати и ключевые пункты договора?
Нет. Сжатие разделяет данные по назначению: текст, печати и схемы проходят по пути с сохранением точности, а избыточные объекты и медиа перекодируются. В открытом тесте документ формата OFD на 443 страницы после сжатия обрабатывался примерно за 124 секунды, при этом чёткость и печати сохранились.
Как именно работает скрытие чувствительного — не пострадает ли текст?
По правилам распознаются и закрываются имена, документы, суммы, коммерческие тайны и прочие категории — всего 13 категорий. Трогается только то, что должно быть скрыто, а смысл основного текста сохраняется максимально. Какие именно поля скрывать, стоит сверить с вашим собственным комплаенс-списком.
В чём разница между приватным развёртыванием и облачной моделью?
Ключевое — где находятся данные. Приватное развёртывание прогоняет препроцессинг и поиск в вашем окружении, документ не покидает внутреннюю сеть. Облачная модель требует, чтобы содержимое ушло наружу. Для договоров, медицинских карт, финансовых данных удержание локально даёт заметно чище комплаенс-картину.
Маленькой команде, у которой документов немного, нужна ли база инженерии данных?
Смотрите на «беспорядок», а не на «объём». Даже пара тысяч файлов, если они разноформатны, содержат чувствительное и должны храниться долго, выигрывают от наблюдаемого препроцессинга — он экономит кучу переделок. При малом объёме проще всего отладить процесс, а потом масштабировать вместе с бизнесом.