Журналист собрал 3000 документов по расследованию: свой поиск по архиву

MAATRIX

Расследование живёт не месяц и не два: оно копится годами, и однажды вы понимаете, что где-то в этих трёх тысячах файлов — выписках, сканах договоров, экспортах из реестров, PDF с показаниями — лежит фраза, которая свяжет два эпизода. Вы точно её видели. Но не помните, в каком файле, в какой папке, в каком письме себе на память. Ctrl+F по одному документу за раз для такого объёма не работает — нужен поиск по всему архиву сразу, и желательно такой, который не живёт на серверах чужой компании.

Когда архив перестаёт быть архивом и становится проблемой

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

Проблема не только в том, что вы теряете время. Она в том, что вы теряете связи. Расследование часто строится не на одном ярком документе, а на совпадении: имя директора всплывает в выписке из ЕГРЮЛ, потом в договоре аренды, потом в протоколе совещания — и только когда вы видите все три упоминания рядом, картина складывается. Если у вас нет способа быстро спросить архив «где ещё встречается эта фамилия», вы физически не можете найти такие совпадения — вы можете только случайно на них наткнуться, перечитывая файлы заново.

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

Почему привычные способы хранения не масштабируются

Три сценария, которые проходит почти каждый журналист, ведущий долгое расследование:

• Папки на диске компьютера. Работает, пока структура одна и её придумали вы сами. Ломается, когда через год вы не помните собственную логику вложенности, а поиск Windows или Spotlight ищет по именам файлов, не по содержимому сканов.
• Почта как архив. Удобно, потому что документы часто и приходят по почте — от источников, юристов, коллег. Но почтовый поиск слаб на вложениях, лимиты на объём ящика подталкивают выгружать старое, а весь архив расследования оказывается заложником одного аккаунта Gmail или Яндекс.Почты, доступного третьей стороне по первому судебному запросу.
• Облачный диск с общей папкой. Решает проблему синхронизации между устройствами, но встроенный поиск большинства облаков (Google Drive, Dropbox, «Яндекс Диск») ищет по названию файла и — в лучшем случае — по тексту, который сервис сумел распознать сам, без вашего контроля над качеством распознавания. А главное: содержимое расследования лежит на инфраструктуре компании, которая по запросу или по собственной политике может ограничить доступ, заблокировать аккаунт или передать данные третьей стороне.

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

Идея: полнотекстовый поиск по всему архиву на своём сервере

Принцип простой и хорошо обкатанный: все документы попадают в одно хранилище на сервере, для каждого извлекается текст (через OCR — оптическое распознавание символов, если это скан или фото), текст индексируется поисковым движком, а вы ищете не по названию файла, а по любому слову или фразе внутри содержимого — и получаете список документов с подсветкой места, где встретилось совпадение.

Технически это собирается из трёх слоёв:

1. Хранилище файлов — сами документы: PDF, DOCX, JPG, PNG, XLSX и так далее, лежащие на диске сервера.
2. OCR-слой — извлечение текста из сканов и фото. Для PDF без текстового слоя и для изображений стандартный открытый инструмент — Tesseract OCR, часто в обвязке ocrmypdf, которая добавляет распознанный текст поверх скана как невидимый слой, не трогая исходное изображение.
3. Поисковый индекс — движок, который хранит извлечённый текст в структуре, оптимизированной под быстрый поиск по словам и фразам, а не движок базы данных общего назначения.

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

Путь первый: готовая система управления документами

Paperless-ngx — открытое приложение именно под этот сценарий: вы скармливаете ему файлы (вручную, через папку для входящих или по почте), оно прогоняет их через OCR, раскладывает по тегам и «корреспондентам» (источникам документа) и даёт полнотекстовый поиск по всему архиву через веб-интерфейс. По сути — персональный аналог CRM для документов, без необходимости самому собирать пайплайн OCR → индекс.

Минимальный запуск через Docker Compose:

services:
  broker:
    image: docker.io/library/redis:7
    restart: unless-stopped
    volumes:
      - redisdata:/data

  db:
    image: docker.io/library/postgres:16
    restart: unless-stopped
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: paperless
      POSTGRES_USER: paperless
      POSTGRES_PASSWORD: замените-на-свой-пароль

  webserver:
    image: ghcr.io/paperless-ngx/paperless-ngx:latest
    restart: unless-stopped
    depends_on:
      - db
      - broker
    ports:
      - "8000:8000"
    volumes:
      - data:/usr/src/paperless/data
      - media:/usr/src/paperless/media
      - ./consume:/usr/src/paperless/consume
    environment:
      PAPERLESS_REDIS: redis://broker:6379
      PAPERLESS_DBHOST: db
      PAPERLESS_DBNAME: paperless
      PAPERLESS_DBUSER: paperless
      PAPERLESS_DBPASS: замените-на-свой-пароль
      PAPERLESS_OCR_LANGUAGE: rus+eng
      PAPERLESS_SECRET_KEY: замените-на-случайную-строку

volumes:
  data:
  media:
  pgdata:
  redisdata:

Кладёте PDF или фото в папку ./consume — сервис сам подхватывает файл, прогоняет через OCR (важно указать rus+eng, если документы на двух языках — иначе распознавание кириллицы будет слабым), добавляет в индекс. Поиск и просмотр — через браузер, включая просмотр оригинала рядом с распознанным текстом, что критично для журналистской работы: вы должны видеть не только «где встретилось слово», но и исходную страницу целиком, чтобы проверить контекст.

Путь второй: своё хранилище плюс отдельный поисковый движок

Если Paperless-ngx кажется избыточным (например, у вас уже есть привычная структура папок и вы не хотите её ломать под чужую систему тегов), можно поднять поиск отдельно от хранения: файлы остаются в файловой системе как есть, а рядом работает поисковый движок — Meilisearch или Typesense, — в который вы индексируете уже извлечённый OCR-текст вместе со ссылкой на путь к оригинальному файлу.

Meilisearch удобен тем, что запускается одной командой и даёт быстрый поиск с опечатками «из коробки» — это важно, если источники или вы сами по-разному транслитерируете иностранные фамилии:

docker run -d --name meilisearch \
  -p 7700:7700 \
  -e MEILI_MASTER_KEY="замените-на-свой-ключ" \
  -v meili_data:/meili_data \
  getmeili/meilisearch:latest

Дальше пишется небольшой скрипт (Python с ocrmypdf/pytesseract для распознавания и requests для отправки в Meilisearch), который проходит по папке с документами, извлекает текст и отправляет в индекс запись с путём к файлу, извлечённым текстом и вашими тегами. Такой вариант требует больше ручной сборки, но даёт полную гибкость: вы решаете, какие метаданные хранить, как группировать документы по эпизодам расследования, как ограничивать поиск по датам или тегам. Для сравнения подходов — какой движок проще поднять и когда переходить на более тяжёлый — есть отдельный разбор: Meilisearch или Typesense: что выгоднее и когда.

Как поднять это на своём сервере пошагово

Практический путь для человека, который не системный администратор, но готов один раз аккуратно всё настроить:

1. Арендуйте сервер. Для архива в несколько тысяч документов с OCR и поиском не нужна мощная машина — начать можно со скромной конфигурации, а нарастить ресурсы позже, если архив разрастётся в разы. Важнее выбрать локацию ближе к вам по задержке и с адекватной юрисдикцией для журналистской работы.
2. Поставьте Docker и Docker Compose — оба инструмента из готового пути ниже используют контейнеры, это экономит время на ручной установке зависимостей.
3. Разверните Paperless-ngx (см. docker-compose.yml выше) или связку «файловое хранилище + Meilisearch/Typesense», если нужна гибкость. Подробный процесс установки поискового движка с нуля разобран в статье как установить и настроить Meilisearch на VPS — там же нюансы по выделению памяти под индекс.
4. Настройте OCR под русский язык. Стандартная поставка Tesseract часто идёт только с английским языковым пакетом — для документов на русском нужно явно подключить rus (в Paperless-ngx это переменная PAPERLESS_OCR_LANGUAGE: rus+eng, при ручной сборке — пакет tesseract-ocr-rus).
5. Перенесите архив. Не пытайтесь загрузить всё за один вечер — OCR на скан-документах требует времени на процессор, особенно если файлов тысячи. Разумно загружать пачками по несколько сотен и проверять качество распознавания на выборке, прежде чем гнать весь массив.
6. Настройте доступ по VPN, а не по открытому порту. Веб-интерфейс Paperless-ngx или API поискового движка не должны торчать в открытый интернет — доступ только через WireGuard-туннель к вашему серверу, даже если вы работаете с телефона в поездке.
7. Заведите резервное копирование — том с документами и базой данных должен бэкапиться на отдельное хранилище, желательно с шифрованием на уровне бэкапа, а не только на уровне диска.

Организация архива: теги, эпизоды, источники

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

• Тег по эпизоду — какой части расследования касается документ (даже если расследование ещё не разбито на главы, черновая разбивка на 5–10 условных линий сильно облегчает жизнь через год).
• Корреспондент/источник — от кого документ получен. В Paperless-ngx это отдельная сущность, по которой тоже можно фильтровать и искать; при самодельной схеме — просто ещё одно поле в индексе.
• Дата документа (не дата загрузки) — для хронологии событий это часто важнее, чем дата, когда файл попал к вам в руки.
• Уровень доверия к источнику — не строгое поле, а скорее заметка: «подтверждено вторым источником», «требует проверки». Такую заметку удобно хранить прямо как текстовый комментарий к документу, который тоже попадает в полнотекстовый индекс — то есть по нему тоже можно будет искать.

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

Безопасность архива и защита источников

Для журналиста-расследователя вопрос не только «как быстро найти документ», но и «кто, кроме меня, может до него добраться». Свой сервер решает первую проблему, но требует внимания ко второй — она не закрывается сама собой фактом аренды VPS.

Базовый набор мер, без которого архив расследования на сервере — риск, а не защита:

• Шифрование диска. Если сервер физически или через панель провайдера может быть доступен кому-то ещё, шифрование тома с документами (LUKS на Linux) защищает архив в случае, если диск или его образ окажется не в тех руках. У шифрования есть свои границы применимости — какие угрозы оно закрывает, а какие нет, разобрано в статье шифрование дисков: что защищает.
• Доступ только через VPN, без открытых портов для веб-интерфейса поиска или панели документов — это резко сокращает поверхность атаки по сравнению с сервисом, торчащим в открытый интернет с логином и паролем.
• Отдельный пользователь и SSH-ключ вместо пароля для входа на сервер — базовая гигиена, но именно она чаще всего оказывается пропущенной на «личном проекте», которым для многих начинается архив расследования.
• Резервные копии с собственным ключом шифрования, а не бэкап в облако общего назначения без шифрования на вашей стороне — иначе весь смысл держать архив вне чужой инфраструктуры теряется на этапе бэкапа.

Здесь стоит быть честным: свой сервер — это защита от компании-провайдера облачного диска, читающей или блокирующей ваш аккаунт, и от массовых утечек чужих сервисов. Это не защита от целенаправленной атаки на конкретно вас со стороны ресурсного противника — против такой угрозы нужны отдельные меры (двухфакторная аутентификация, физическая безопасность устройств, операционная дисциплина), которые выходят за рамки настройки поиска по документам.

Частые вопросы