Onyx (Danswer): поиск по корпоративным знаниям

MAATRIX

У любой компании старше пары лет знания расползаются по десятку систем: часть в Confluence, часть в тикетах Jira или Zendesk, часть — в переписке Slack или Telegram, часть вообще только в головах у сотрудников, которые ушли в отпуск. Найти ответ на конкретный вопрос означает вспомнить, где именно он лежит, и вручную обойти два-три поисковых интерфейса. Onyx (бывший Danswer) — open source инструмент, который индексирует все эти источники разом и даёт один чат, куда можно задать вопрос на человеческом языке и получить ответ со ссылками на первоисточники.

Зачем вообще нужен единый ИИ-поиск

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

Onyx решает это не заменой существующих систем, а надстройкой над ними. Он подключается к источникам через коннекторы, индексирует контент в векторную базу и поднимает поверх неё RAG-конвейер (retrieval-augmented generation) — то есть ищет релевантные фрагменты и отдаёт их языковой модели вместе с вопросом, чтобы получить связный ответ, а не список ссылок. Разница с обычным полнотекстовым поиском в том, что вопрос можно сформулировать своими словами, а не гадать точные ключевые слова, под которыми документ был написан три года назад. О том, что происходит внутри такого конвейера между вопросом и ответом, подробно разобрано в статье про механику RAG — тем, кто настраивает Onyx, полезно понимать эту кухню, чтобы объяснять коллегам, почему иногда ответ неточный или неполный.

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

Разграничение прав доступа — критически важный момент

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

Onyx умеет решать эту задачу через механизм, который в проекте называется document-level permissions (или connector-based access control) — при индексации коннектор должен не только вытащить контент, но и сохранить информацию о том, кто имеет право его видеть в исходной системе, и на уровне поиска Onyx обязан фильтровать результаты по правам конкретного пользователя, который задаёт вопрос. Это работает надёжно только тогда, когда:

• коннектор конкретного источника реально поддерживает синхронизацию прав (permission sync), а не просто индексирует весь контент, к которому есть доступ у сервисного аккаунта интеграции;
• в Onyx настроена аутентификация пользователей (SSO/OIDC), которая сопоставляет реального сотрудника, задающего вопрос, с его правами в исходных системах — иначе фильтровать не по кому;
• права синхронизируются регулярно, а не один раз при подключении — уволенный сотрудник или снятый с проекта человек не должен продолжать видеть его тикеты через ИИ-поиск ещё полгода.

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

Практический совет: прежде чем открывать Onyx на всю компанию, устройте тест на разграничение прав специально. Заведите тестового пользователя с ограниченными правами в исходной системе (например, обычного сотрудника без доступа к HR-папке), спросите у Onyx что-то, что должно быть скрыто, и убедитесь, что ответа нет или он честно говорит «не нашёл». Если ответ находится — значит синхронизация прав не работает так, как вы думали, и разворачивать систему на всех рано.

Как устроена архитектура

Onyx — self-hosted проект, разворачивается через Docker Compose и состоит из нескольких сервисов: API-сервер, веб-интерфейс, воркеры индексации (background workers, которые периодически опрашивают источники и обновляют индекс), векторная база (обычно PostgreSQL с расширением pgvector, либо отдельный vector store) и опционально Redis для очередей задач. Языковую модель для генерации ответов можно подключить как через облачный API (OpenAI, Anthropic), так и через локально развёрнутую модель — например, через Ollama или vLLM, если данные компании не должны покидать периметр.

Минимальный запуск через официальный docker-compose:

git clone https://github.com/onyx-dot-app/onyx.git
cd onyx/deployment/docker_compose
cp .env.example .env
# отредактировать .env: указать модель, ключи API, домен
docker compose -f docker-compose.dev.yml up -d

Для продакшена в документации есть отдельный compose-файл с вынесенным Postgres и обязательным HTTPS через reverse proxy — self-signed или Let's Encrypt сертификат на своём домене, поскольку веб-интерфейс без шифрования отдавать сотрудникам компании не стоит. Под нагрузку в несколько десятков одновременных пользователей и пару миллионов проиндексированных документов реалистично закладывать сервер с 8-16 GB RAM и несколькими ядрами CPU только под сам Onyx — конкретные цифры сильно зависят от объёма контента и частоты переиндексации, поэтому это ориентир, а не гарантия, и его стоит проверить на своём объёме данных до конечного решения о конфигурации сервера.

Сложность интеграции множества разных источников

Здесь стоит быть честным: интеграция «единой точки поиска по всем системам» звучит красиво в маркетинговом описании, но на практике каждый источник — это отдельный API, отдельный формат данных и отдельная логика извлечения прав доступа. У Onyx есть готовые коннекторы к десяткам систем — Confluence, Jira, Slack, Google Drive, Notion, GitHub, Zendesk, Gmail и другие, — но качество и глубина этих коннекторов заметно различаются.

Часть коннекторов (Confluence, Slack, Google Drive) поддерживаются давно, стабильно синхронизируют и контент, и права доступа. Часть — свежие или менее популярные — могут индексировать контент, но не полностью поддерживать permission sync, либо требовать более широких прав сервисного аккаунта, чем хотелось бы дать. Список поддерживаемых коннекторов и статус каждого стоит проверять в актуальной документации проекта на GitHub перед тем, как обещать руководству «подключим всё за неделю» — некоторые интеграции пишутся под конкретный тариф API исходной системы (например, Jira Cloud и Jira Server имеют разные API и разную степень поддержки), и то, что заявлено как «поддерживается», иногда означает базовое чтение контента без тонкой настройки прав.

Практическая рекомендация — прежде чем закладывать Onyx в план внедрения, составьте список реальных источников знаний вашей компании (обычно это 3-5 систем, а не десяток) и для каждого явно проверьте в документации Onyx: есть ли готовый коннектор, поддерживает ли он permission sync, и какие права нужны сервисному аккаунту интеграции в исходной системе. Если для ключевого источника (например, внутренней Wiki на самописном движке или специфичной CRM) готового коннектора нет — придётся либо писать свой через API Onyx, либо смириться с тем, что этот источник не попадёт в единый поиск, либо экспортировать его контент в поддерживаемую систему.

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

Сравнение источников по готовности коннектора

Таблица упрощена и приведена как ориентир для планирования — точный список поддерживаемых систем и их актуальный статус нужно смотреть в документации проекта на момент внедрения, поскольку список коннекторов активно пополняется.

Развёртывание пилота: с чего начать

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

1. Выберите один-два источника, где реально скапливается больше всего повторяющихся вопросов — чаще всего это внутренняя документация (Confluence/Notion) плюс тикет-система поддержки.
2. Разверните Onyx на тестовом сервере, подключите эти источники, дайте доступ ограниченной группе — например, только команде поддержки из 3-5 человек.
3. Обязательно протестируйте разграничение прав так, как описано выше — заведите пользователя с урезанными правами и проверьте, что чувствительный контент ему недоступен через поиск.
4. Соберите обратную связь за 2-4 недели: насколько ответы точны, сколько времени реально экономится, какие источники стоит добавить следующими.
5. Только после этого расширяйте на остальные источники и остальную компанию, повторяя проверку прав для каждого нового коннектора отдельно — а не одним общим тестом на старте.

Такой подход дороже по времени на старте, но значительно дешевле по риску, чем «включить всё и разобраться по ходу» — особенно если среди источников есть HR-документы, финансовые данные или переписка с клиентами. Компаниям, которые уже задумывались о базе знаний с ИИ, но не решались из-за вопроса разграничения доступа, имеет смысл сравнить готовые подходы в статье про корпоративную базу знаний на VPS с ИИ — там разбираются альтернативные варианты, включая более простые схемы без множества источников сразу.

Где Onyx уместен, а где нет

Onyx хорошо решает задачу, когда у компании уже есть несколько устоявшихся систем хранения знаний и в них накопился реальный объём контента — от нескольких сотен документов и тикетов. Если у компании один источник знаний (например, только Confluence) и небольшой объём документов, то более простое решение — RAG поверх одной системы без сложной инфраструктуры разграничения прав между источниками — может быть избыточно, и стоит присмотреться к варианту попроще, например к тому, как поднять RAG по своим документам на сервере без коннекторов к десятку внешних систем.

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

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