VPS для юридической фирмы: своя база знаний с ИИ

MAATRIX

Юрист тратит вечер на поиск одного пункта — в договоре трёхлетней давности, в переписке по делу, в судебном решении, которое где-то уже комментировали. Архив есть, но он не ищется: файлы разложены по папкам с именами вроде «Договор_финал_2» и «Договор_финал_2_испр», а нужная формулировка всплывает в памяти смутно — «было что-то про форс-мажор в одном из договоров с этим контрагентом». Загрузить всё в облачный ChatGPT и спросить напрямую нельзя: в архиве — данные доверителей, условия сделок, переписка под NDA, и адвокатская тайна не снимается тем, что вопрос задаёт нейросеть, а не человек. Решение — не отказ от ИИ, а перенос его на свою инфраструктуру: сервер, на котором документы остаются внутри фирмы, а поиск и ответы даёт локальная база знаний с RAG.

Почему облачный ИИ — не вариант для юридической фирмы

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

Адвокатская тайна и режим конфиденциальности по соглашению с доверителем не делают исключения для «умного помощника»: раскрытием считается любая передача материалов дела за пределы уполномоченного круга лиц, включая облачный сервис, чьи условия использования разрешают анализировать загруженный контент. Договоры с клиентами и партнёрами всё чаще прямо запрещают передачу документов третьим лицам без письменного согласия, а если фирма обрабатывает персональные данные доверителей на территории России, добавляется ещё и 152-ФЗ с требованиями к месту хранения. Это не юридическая консультация, а техническое замечание: что закон требует именно в вашем случае, лучше сверить заранее — общий разбор подходов к размещению есть в материале «152-ФЗ: где законно держать сервер с персональными данными».

Облачный ИИ хорош для черновика письма или обобщения открытой судебной практики, но не для работы с материалами конкретных дел. Как только в промпт попадает имя доверителя, номер дела или условие реальной сделки — это уже утечка, и от того, что интерфейс называется «ассистентом», а не «выгрузкой данных», ничего не меняется.

Что даёт свой сервер с базой знаний

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

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

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

Какую конфигурацию VPS выбрать под архив документов

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

Если фирма использует внешнюю модель (например, через API OpenAI или Anthropic) только для генерации ответов, а на сервере остаётся хранилище документов, индекс для поиска и векторная база, требования скромные: 4 vCPU, 8–16 ГБ RAM, 100–200 ГБ NVMe — этого достаточно для архива на несколько тысяч документов. На сторону провайдера при этом уходит не сам документ, а только релевантный фрагмент и короткий вопрос — но это всё ещё передача данных за пределы фирмы, и её стоит явно обсудить с точки зрения NDA.

Если требование — вообще ничего не отправлять наружу, модель разворачивается локально на этом же сервере, и требования другие: локальная языковая модель ощутимо прожорливее к памяти. Для модели среднего размера (7–14 млрд параметров), которой достаточно для работы с текстом договоров, нужно от 32 ГБ RAM и GPU с 16–24 ГБ видеопамяти; без GPU модель тоже запустится, но скорость ответа упадёт до уровня, неудобного для постоянной работы.

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

Локация сервера — вопрос не только скорости. Если фирма обрабатывает персональные данные доверителей-физлиц и по 152-ФЗ обязана хранить их на территории России, разумный выбор — российская площадка. Если работа идёт преимущественно с юрлицами, иностранными контрагентами или данными вне требований локализации, можно рассматривать зарубежную локацию — она часто даёт более стабильный доступ к внешним API без прокси. Повторим оговорку: это техническое соображение, а не правовая оценка — какие данные считаются персональными и обязательна ли локализация, решает юрист фирмы, а не хостинг-провайдер.

Установка AnythingLLM: база знаний с RAG-поиском

AnythingLLM — открытый инструмент, который берёт на себя всю обвязку вокруг RAG (retrieval-augmented generation): разбивает документы на фрагменты, строит по ним векторный индекс, при вопросе находит релевантные куски текста и передаёт их модели вместе с вопросом, чтобы ответ опирался на реальный документ, а не на догадку модели. Модель может быть локальной или внешней по API — выбор конфигурируется в интерфейсе, ключи от внешних сервисов не обязательны. Пошаговый разбор конфигурации есть в отдельном материале — «Как установить и настроить AnythingLLM на VPS», здесь — минимум, чтобы поднять сервис под задачу юрфирмы.

Проще всего поднять AnythingLLM через Docker на чистом VPS с Ubuntu:

sudo apt update && sudo apt install -y docker.io docker-compose-plugin
sudo mkdir -p /opt/anythingllm/storage
sudo docker run -d -p 3001:3001 \
  --name anythingllm \
  --restart unless-stopped \
  -v /opt/anythingllm/storage:/app/server/storage \
  -e STORAGE_DIR="/app/server/storage" \
  mintplexlabs/anythingllm

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

sudo ufw allow 22/tcp
sudo ufw allow 443/tcp
sudo ufw deny 3001/tcp
sudo ufw enable

Дальше в веб-интерфейсе указывается провайдер модели — локальная модель через встроенный движок либо ключ API внешнего провайдера, если фирма решила использовать внешнюю модель только для генерации текста. Отдельно настраивается провайдер эмбеддингов — он превращает текст в векторы для поиска, и его тоже можно оставить локальным, чтобы содержимое документов не покидало сервер даже на этапе индексации.

Регулярное резервное копирование папки /opt/anythingllm/storage — не опция, а обязательный пункт: там лежат и загруженные документы, и векторный индекс, и история переписки с системой.

tar -czf /backup/anythingllm-$(date +%F).tar.gz /opt/anythingllm/storage

Доступ для команды: workspace на юриста и разграничение прав

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

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

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

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

Как структурировать документы для загрузки

Качество ответов системы напрямую зависит от того, насколько внятно организован архив до загрузки — RAG-поиск находит текстовые фрагменты, и чем точнее они привязаны к делу, тем точнее ответ.

Рабочая структура — папка на каждое дело или каждого клиента, внутри неё подпапки по типу документа: договоры, переписка, процессуальные документы, судебные акты. Имя файла должно нести смысл без открытия: не «Документ1.pdf», а «Договор_поставки_ООО_Ромашка_2024-03-15.pdf» — при построении индекса имя файла часто становится частью метаданных, по которым система понимает контекст фрагмента.

Сканы и фотографии документов AnythingLLM распознаёт через встроенный OCR, но качество распознавания заметно ниже, чем у текстового PDF или Word — если есть исходный текстовый файл, грузите его вместо скана. Для больших архивов, которые копились годами в бумаге, разумно выделить отдельный этап: сначала прогнать пачку сканов через OCR и проверить результат, и только потом загружать в базу знаний.

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

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

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