Внутренняя база знаний компании на VPS с ИИ-поиском

MAATRIX

Знания компании обычно разбросаны по десяткам мест: часть — в Google Docs, часть — в заметках в Notion или похожем инструменте, часть — в переписке в мессенджере, а часть вообще живёт только в голове у одного сотрудника, который два года назад настраивал процесс и с тех пор его никто не трогал. Новый человек в команде тратит первую неделю не на работу, а на то, чтобы понять, где искать ответ на простой вопрос: как оформить отпуск, какой у нас процесс релиза, кто отвечает за интеграцию с платёжным провайдером. Старые сотрудники тоже не выигрывают — они просто научились спрашивать в чате у коллег вместо того, чтобы искать в вики, потому что поиск по вики почти никогда не находит то, что нужно, если формулировка не совпадает дословно. Решение — не ещё одна вики, а база знаний с ИИ-поиском, которая читает все документы компании и отвечает на вопросы обычным языком, при этом стоит на собственном сервере, а не в чужом облаке.

Чем это отличается от обычной вики

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

База знаний с ИИ-поиском работает иначе. Документы индексируются не как текст для полнотекстового поиска, а как смысловые фрагменты — система понимает, о чём вопрос, даже если он сформулирован не так, как в документе. На вопрос «как оформить отпуск, если я в командировке» инструмент не выдаст список файлов, где встречается слово «отпуск», а соберёт ответ из релевантных фрагментов регламента и напишет его обычным языком, со ссылкой на источник — конкретный документ и место в нём, чтобы можно было проверить. Это и есть RAG (retrieval-augmented generation) — подход, при котором языковая модель отвечает не по общим знаниям, а строго по загруженным документам компании. Подробнее о механике такого поиска — в статье как поднять RAG по своим документам на сервере.

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

Почему на своём сервере, а не в облачном SaaS

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

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

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

Выбор инструмента: AnythingLLM или Dify

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

AnythingLLM — это готовый инструмент именно под задачу «загрузить документы, получить чат-поиск по ним». У него есть понятие workspace (рабочее пространство) — можно завести отдельный workspace на отдел или на проект, загрузить туда документы, и модель будет отвечать только в контексте этого набора. Интерфейс простой, разворачивается за одну команду, подходит компаниям, которым нужен именно поиск и ответы по документам, без сложной логики вокруг.

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

Для большинства компаний, которым нужна именно база знаний с поиском — HR, продуктовой команде, поддержке — AnythingLLM закрывает задачу быстрее и с меньшим количеством настроек. Дальше в статье используется именно он, а полное сравнение подходов — в материале AnythingLLM против Dify: что выгоднее и когда.

Установка на VPS

Для базы знаний на несколько отделов с умеренной нагрузкой достаточно VPS с 4 ядрами и 8 ГБ оперативной памяти — этого хватит, если языковая модель будет вызываться через внешний API (например, у крупных провайдеров). Если планируется полностью локальная модель без обращений наружу, память и видеопамять нужно подбирать под конкретную модель — это отдельный вопрос, разобранный в статье сколько RAM нужно для AnythingLLM.

Самый простой способ поднять AnythingLLM на чистом сервере с Ubuntu — через Docker:

apt update && apt install -y docker.io docker-compose-plugin
mkdir -p /opt/anythingllm/storage
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 и авторизацией:

apt install -y nginx certbot python3-certbot-nginx
certbot --nginx -d kb.company.example

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

Структура базы: workspace по отделам

Ключевое архитектурное решение — не сваливать все документы компании в одно общее пространство. У AnythingLLM для этого есть workspace: логически изолированный набор документов со своей историей переписки. Разумная структура для компании среднего размера выглядит так:

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

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

Если компания хранит основной объём документов в PDF (сканы договоров, инструкции, презентации), удобно сразу продумать процесс регулярной выгрузки — про это подробнее в материале про RAG по своим PDF без облака на VPS.

Права доступа: кто что видит

По умолчанию в AnythingLLM есть роли — администратор, менеджер и обычный пользователь, и доступ к workspace настраивается на уровне каждого пространства отдельно. Разумная модель для компании:

• Администратор — один-два человека (обычно ИТ или руководитель проекта внедрения), у них полный доступ ко всем workspace и настройкам.
• Менеджеры отделов получают права на управление документами в workspace своего отдела — могут загружать и удалять файлы, но не видят настройки сервера.
• Обычные сотрудники получают доступ на чтение только к тем workspace, которые относятся к их отделу и к общему пространству.

Важно не пропустить момент с чувствительными данными: если в документах поддержки или HR встречаются персональные данные клиентов или сотрудников, доступ к соответствующему workspace должен быть ограничен строго тем, кому это нужно по работе, а не открыт всей компании «на всякий случай». Это же касается истории переписки с ИИ внутри workspace — она тоже видна тем, у кого есть доступ к пространству, так что стоит заранее решить, кто может просматривать чужие запросы.

Поддержание базы в актуальном состоянии

База знаний, которую загрузили один раз и забыли, довольно быстро становится источником неправильных ответов — а неправильный ответ от ИИ, который звучит уверенно, опаснее, чем отсутствие ответа вообще. Здесь стоит сразу договориться о процессе, а не полагаться на то, что кто-то вспомнит обновить документ.

Практический подход:

1. Назначить ответственного за каждый workspace — обычно это тот же человек, который отвечает за соответствующий регламент в компании.
2. Завести правило: документ обновился — его перезаливают в базу в тот же день, а не «когда будет время». Устаревшая версия должна быть удалена из workspace, а не просто дополнена новой — иначе ИИ может процитировать старую формулировку, потому что технически она тоже есть в индексе.
3. Раз в квартал делать ревизию — просматривать список документов в каждом workspace и убирать то, что устарело окончательно (закрытые проекты, отменённые процессы).

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

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