Поиск по внутренним документам почти всегда начинается одинаково. Сначала вы обнаруживаете хаос в папках, потом попытки «сделать внутренний поисковик», потом загрузка файлов в облачные сервисы типа NotebookLM. На шаге отправки в облако как раз нарушается политика безопасности. И по статистике Gartner так делает 75% сотрудников. Есть ли выход?
Существует такой инструмент как RAG. Он отлично подходит, чтобы решить задачу поиска по вашим корпоративной базе знаний. Данные перестают быть файлами и становятся векторными представлениями.
Разберём три рабочих подхода без иллюзий и без попыток выдать один инструмент за универсальное решение.
AnythingLLM как быстрый вход в локальный RAG
AnythingLLM типичный сервис для этого. Установка занимает минимум времени. Интерфейс понятен без обучения сотрудников.
И что самое важно для безопасности: документы загружаются в локальную базу. Система индексирует их и строит векторное представление. После этого появляется чат, который выдает любому сотруднику информацию по собранной корпоративной базе.
Такой подход часто используют как пилот внутри компании.
Практическая ценность:
- быстрый старт без разработки собственного контура
- локальное хранение индексов
- отсутствие зависимости от внешнего API
Ограничения проявляются быстро. При росте объёма документов нагрузка на CPU и GPU резко растёт. Без видеокарты система начинает тормозить. Архитектура безопасности зависит не от инструмента, а от конкретной установки. Общий доступ ломает идею локальности.
AnythingLLM работает во время тестов. В промышленной среде требует аккуратного разворачивания и контроля инфраструктуры.
Ollama и Qwen как изолированный контур
Ollama вместе с Qwen формируют другой класс системы. Здесь нет зависимости от облака.
Модель запускается внутри локального окружения. Индексы и embeddings формируются на том же железе. При необходимости сеть отключается физически, и система продолжает работать.
Такой подход используют там, где утечка данных недопустима по определению.
Сильные стороны:
- полный контроль над данными
- отсутствие внешних API и логирования на стороне провайдера
- возможность построить автономный контур
Ограничения:
- настройка требует инженерной подготовки
- качество ответа зависит от модели и параметров инференса
- ошибка в конфигурации ухудшает либо скорость, либо точность
Этот вариант используют там, где безопасность важнее удобства. Часто такой RAG становится частью закрытых корпоративных контуров.
Obsidian как граф знаний вместо классического поиска
Obsidian меняет саму идею работы с документами. Поиск уходит на второй план. Основной эффект появляется за счёт связей между заметками.
Документы перестают существовать как отдельные файлы. Система связывает их через ссылки и контекст. Формируется граф знаний, где ответ строится из структуры всей базы.
Такой подход используют в личных системах знаний и небольших командах.
Практические особенности:
- сильный эффект при хорошо структурированных заметках
- ценность перекрёстных ссылок
- возможность подключить локальный ИИ и превратить систему в RAG поверх графа
Без дисциплины в ведении базы знаний система превращается в набор разрозненных заметок. Масштабирование требует архитектуры данных.
Ошибка, которую повторяют почти все
Облачные RAG-обёртки выглядят простым решением. Документы загружаются в сервис, добавляется чат, задача формально закрывается.
Проблема появляется позже. Семантический слой данных уходит наружу. Даже если файлы остаются внутри компании, embeddings и контекст обрабатывает внешний сервис.
Утечка происходит не на уровне файлов, а на уровне смыслов. Иногда достаточно восстановить структуру знаний без исходных документов.
Поэтому выбор RAG связан не с интерфейсом, а с моделью угроз. При критичных данных внешний контур исключается полностью.
Вывод
RAG внутри компании нельзя свести к одному классу решений. Каждый подход решает свою задачу.
> AnythingLLM подходит для быстрого старта.
> Ollama с локальной моделью закрывает задачу полной изоляции.
> Obsidian формирует систему, где поиск заменяется структурой знаний.
Общий принцип один. Контроль над данными важнее удобства. Потеря контроля превращает RAG в канал утечки, даже если файлы формально остаются внутри компании.
Как правильно делать поиск по внутренним знаниям компании
Поиск по внутренним знаниям редко ломается из-за моделей. Проблемы начинаются раньше, на уровне данных и архитектуры. Большинство компаний не проектирует ни саму систему хранения ни систему извлечения знаний.
Корпоративный поиск работает нормально только тогда, когда разделены три вещи:
- структура данных,
- семантика и
- контроль доступа.
Разделение типов запросов
Внутренний поиск обслуживает разные классы задач. Их смешивание ухудшает результат.
Фактические запросы касаются конкретных документов и версий. Контекстные запросы требуют понимания причин и истории решений. Синтетические запросы собирают информацию из нескольких источников и формируют вывод.
Если обрабатывать все через один механизм поиска, модель начинает подменять факты догадками.
Контент важнее модели
Качество поиска определяется структурой данных, а не выбором LLM.
Хаотичные файловые хранилища, дубли документов и отсутствие версий разрушают даже хорошо настроенный RAG. Без управления контентом модель работает поверх шума.
Архитектура нормального корпоративного поиска
Рабочая схема состоит из нескольких слоёв. Каждый слой решает свою задачу и не смешивается с другими.
Ingestion слой
Парсинг PDF, DOCX, Confluence, email. Нормализация текста. Удаление мусора, включая подписи и повторяющиеся футеры.
Семантический слой
Embeddings. Чанкинг по смыслу, а не по символам. Хранение версий документов для отслеживания изменений.
Retrieval слой
Hybrid search: BM25 + vector search. Фильтрация по метаданным, включая дату, отдел и права доступа.
Reranking слой
Отдельная модель или LLM выполняет отбор 5–10 наиболее релевантных фрагментов. Этот слой критичен для точности ответов.
LLM слой
Финальная сборка ответа. Без доступа к сырому массиву документов. Только обработанный и отфильтрованный контекст.
Если убрать reranking, система начинает уверенно выдавать неправильные ответы.
Безопасность и доступ
Локальное развертывание не гарантирует безопасность. Утечки происходят через индексацию без учета прав доступа и retrieval без ролей пользователей.
Embeddings должны хранить информацию о доступе. Поиск обязан учитывать ACL на уровне каждого фрагмента текста.
Главная проблема RAG в компаниях
Система начинает «знать больше, чем пользователь должен видеть».
Это не баг модели. Это ошибка архитектуры доступа.
Нормальная схема:
- retrieval всегда учитывает права пользователя
- документы режутся не только по смыслу, но и по доступу
- embeddings хранятся с ACL-метками
Если этого нет, любой RAG превращается в утечку через поиск.
Безопасность начинается не с LLM
Частая иллюзия: «если модель локальная, значит безопасно».
Реальные утечки происходят на других уровнях:
- индексирование чувствительных документов без ACL
- embeddings без разграничения доступа
- retrieval без учета ролей пользователя
- логирование запросов в сторонние системы
LLM здесь последний слой риска, а не первый.
Облачные RAG и ложное ощущение контроля
Облачные решения часто решают интерфейс, но не решают модель угроз.
Семантический слой данных уходит наружу вместе с embeddings. Даже при хранении файлов внутри компании структура знаний оказывается за пределами контроля.
Вывод
Корпоративный поиск работает только при правильной архитектуре данных.
Система должна строиться снизу вверх: контент, семантика, retrieval, reranking и только потом LLM.
Если поменять порядок, RAG превращается в систему уверенных, но случайных ответов.