Комментарии 12
Чувствительные корпоративные данные обрабатываются локальными моделями внутри защищённого контура
А что за локлаьные модели?
интерактивный чат со стримингом ответов
Посмотрите в сторону AG-UI.
Не то что вот прям стандарт, но встроенных фич даже в базовых TS библиотеках достаточно приличная
Да, интересно, какие локальные модели используются, и какие мощности под них развернуты?
Как раз прохожу весь ваш путь в разработке своего приложения по написанию вики и лорных вселенных. С мощным рендером читалок HTML, md, PDF и тд. Мучаюсь с подбором мультиязычных недорогих эмбеддинг моделей, по этому спасибо за наводку на FRIDA. Пока не рисковал ее потестить, теперь наверстаю.
По RAG очень важно учесть суммаризацию данных как по чанкам, так и по мелким файлам, где можно избежать чанкования.
Спасибо за отличный пост, всегда интересно узнать, как у остальных))) Потому что сейчас так много и продуктов и возможностей и моделей. Тут конечно вопросов больше чем ответов, а ответы становятся legacy в течение месяца. Мне лично интересен security trimming и как применяется он у вас, потому что разные пользователи, должны видеть один и тот же ответ по-разному в зависимости от прав. Было бы супер узнать, и.к. мы реализовывали как отдельный инстанс который знает всё обо всех правах всегда, как нода внутри большого поискового ИИ агента.
Для авторизации пользователя мы используем корпоративную SSO — в ней есть информация обо всех доступах пользователя. Эта информация загружается для пользователя во время его сессии с Юджином. В БД для каждого чанка указаны его группы доступов в метаинформации. Далее мы смотрим — если два множества пересекаются — доступы пользователя и доступы чанка — значит найденный чанк попадёт в контекст, если нет, то в контекст LLM чанк добавлен не будет.
Разные отделы имеют доступ к разной информации. Как решили вопрос с правами доступа к информации?
В Wiki есть критичная и конфиденциальная информация, она тоже попадает в индекс?
Аутентификация пользователей реализована через корпоративный SSO-сервис, который хранит полную карту доступов каждого сотрудника. Эти данные подгружаются в момент начала рабочей сессии с Юджином. На уровне БД каждый чанк содержит в метаданных перечень групп, которым он доступен. Дальше работает простая логика: система проверяет пересечение двух наборов — прав пользователя и требуемых разрешений для чанка. Есть пересечение — чанк отправляется в контекст. Нет пересечения — фрагмент отсекается и в LLM не передаётся.
Отвечая на вопрос, может ли быть конфиденциальная информация в индексе, — да, может, поэтому используются строго внутренние модели для определённых источников.
Прикольно. А вычислительные мощности какие используются?
Тоже разворачивал нечто подобное локально.
GPU: L40S 46GB
LLM: Gemma-4-26B-A4B Q4
Embeddings: Qwen3-Embedding-8B Q5
Reranker: Qwen3-Reranker-4B. Q5
На 6500+ книжек - солянке из англо-русско-французских текстов. Отвечает.
Долго (что лечится более мощной карточкой и размерами батчей реранкера).
Не идеально на больших таблицах (что лечится ручным ocr).
Вполне рабочий вариант.
Как мы создали внутреннего ИИ-помощника на базе RAG и перестали искать ответы по корпоративной Wiki