Локальный RAG по внутренней документации: поиск-ассистент для команды

В этой статье разберём, как создать локального ИИ-ассистента, который ищет информацию во внутренних регламентах, проектах, инструкциях, отчётах, технических заданиях и другой документации компании. Материал будет полезен инженерным и проектным отделам, ИТ-командам и руководителям, которые хотят ускорить поиск знаний, но не готовы передавать документы во внешние облачные сервисы. Вы узнаете, как работает локальный RAG, из каких компонентов состоит система, как разграничить доступ сотрудников, выбрать модель и определить, когда хватит одной рабочей станции, а когда потребуется Devbox AI.

Локальный RAG не заменяет систему документооборота и не «обучает нейросеть на всех файлах компании». Он создаёт дополнительный слой поиска: сотрудник задаёт вопрос обычным языком, система находит подходящие фрагменты документов и формирует ответ со ссылками на источники.

Коротко

• RAG соединяет языковую модель с внутренней базой документов.
• Модель отвечает не только на основе собственных знаний, но и с учётом найденных фрагментов.
• Документы, векторная база и модель могут работать полностью внутри инфраструктуры компании.
• Локальное размещение сокращает передачу персональных и конфиденциальных данных третьим лицам.
• Развёртывание внутри компании само по себе не обеспечивает соответствие 152-ФЗ.
• Качество зависит не только от размера языковой модели, но и от подготовки документов, поиска, метаданных и проверки результатов.
• Для пилота и одного отдела обычно достаточно системы с одной GPU.
• Для общего сервиса нескольких подразделений, высокой нагрузки или нескольких моделей лучше использовать Devbox AI.
• Ассистент должен показывать источники и отказываться от ответа, когда база не содержит нужной информации.

Что такое RAG

RAG — это генерация с дополнением из базы знаний, от английского Retrieval-Augmented Generation.

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

RAG добавляет перед генерацией отдельный этап поиска:

1. пользователь задаёт вопрос;
2. система ищет подходящие фрагменты во внутренних документах;
3. передаёт найденный контекст языковой модели;
4. модель формирует ответ;
5. интерфейс показывает использованные источники.

Например, инженер спрашивает: «Какой момент затяжки указан для крепления узла А-17?».

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

Чем RAG отличается от обычного поиска

Полнотекстовый поиск хорошо находит точные слова, артикулы, номера проектов и названия деталей. Но он может пропустить документ, если пользователь сформулировал вопрос иначе.

Допустим, в регламенте написано: «Перед запуском установки оператор обязан проверить герметичность соединений».

А сотрудник спрашивает: «Что нужно осмотреть перед включением оборудования?».

Слова почти не совпадают, но смысл одинаковый. Смысловой поиск преобразует запрос и документы в числовые представления — эмбеддинги или векторы — и сравнивает их близость.

Полностью отказываться от точного поиска не стоит. В инженерной документации часто встречаются:

• артикулы;
• номера чертежей;
• обозначения ГОСТ;
• коды ошибок;
• версии программ;
• адреса оборудования;
• сокращения;
• фамилии и номера договоров.

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

Что получает команда

Быстрый поиск по разрозненной документации

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

Единое окно для разных источников

Локальная база знаний с ИИ может объединять:

• сетевые папки;
• систему электронного документооборота;
• Wiki;
• Git-репозитории;
• базу технической поддержки;
• инструкции;
• проектные отчёты;
• стандарты;
• протоколы испытаний;
• документацию по программному обеспечению.

Система не обязана физически переносить все файлы в одно хранилище. Она может индексировать разрешённые источники и сохранять ссылки на оригиналы.

Быстрое введение новых сотрудников в работу

Новый инженер сможет спросить, как команда оформляет результаты испытаний, где лежит шаблон расчёта или какие ограничения выявили в предыдущем проекте.

Ассистент не заменит наставника, но сократит количество повторяющихся вопросов.

Ответы с опорой на действующие версии

При правильной настройке система учитывает дату, статус и версию документа. Она может отдавать приоритет действующему регламенту и предупреждать, что найденный файл устарел.

Сохранение знаний после ухода специалиста

Часть корпоративного опыта хранится в отчётах, переписке и проектных заметках, которые сложно найти обычным поиском. RAG помогает извлекать эти знания, но только в том случае, если компания сохранила материалы и разрешила системе их индексировать.

Для каких отделов подходит локальный RAG

Инженерные и конструкторские подразделения

Ассистент ищет требования, результаты прошлых испытаний, характеристики компонентов, причины принятых решений и связанные чертежи.

Он может отвечать на вопросы:

• Какие ограничения обнаружили в прошлой версии изделия?
• Какая марка материала указана в спецификации?
• Где описана методика приёмочных испытаний?
• Почему изменили геометрию детали?
• В каких проектах уже использовали этот узел?

Проектные отделы

Система помогает работать с техническими заданиями, протоколами встреч, сметами, требованиями заказчиков и историей изменений.

ИТ-команды

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

Пример запроса: «После какого обновления появилась эта ошибка и как её устраняли раньше?».

Служба эксплуатации

Ассистент находит порядок обслуживания, интервалы проверок, предупреждения и инструкции по устранению неисправностей.

Внутренняя поддержка

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

Почему RAG стоит разворачивать локально

Документы не нужно загружать во внешнее облако

Внутренние материалы могут содержать:

• персональные данные сотрудников и клиентов;
• сведения о договорах;
• коммерческие предложения;
• чертежи;
• исходный код;
• результаты исследований;
• финансовые показатели;
• данные об инфраструктуре;
• информацию о выявленных уязвимостях.

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

Это не делает систему неуязвимой, но сокращает число внешних участников, которым компания передаёт данные.

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

Внешний поставщик может изменить тарифы, модели, ограничения или условия использования. On-premise RAG продолжает работать на зафиксированных версиях программ и моделей даже без подключения к интернету.

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

Можно настроить доступ до уровня документа

Сотрудник проектного отдела не должен получать результаты из файлов бухгалтерии только потому, что обе папки попали в одну векторную базу.

Локальный RAG должен проверять права пользователя до поиска или фильтровать результаты по метаданным:

• отдел;
• проект;
• уровень конфиденциальности;
• юридическое лицо;
• группа пользователей;
• срок действия доступа.

Расходы не зависят от каждого запроса к облачной модели

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

Локальное размещение и 152-ФЗ

Локальный ИИ по базе знаний on-premise упрощает контроль за персональными данными, но сам факт установки сервера в офисе не обеспечивает соответствие 152-ФЗ (Федеральный закон о персональных данных).

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

Перед запуском компании нужно определить:

• какие персональные данные попадают в систему;
• на каком основании она их обрабатывает;
• кто получает доступ;
• какие действия система записывает в журнал;
• где хранятся запросы и ответы;
• как долго сохраняются данные;
• как компания удаляет документы из индекса;
• как она реагирует на инциденты.

Правовую и техническую схему следует согласовать со специалистами по персональным данным и информационной безопасности.

Что меняется при работе с коммерческой тайной

Локальный сервер сам по себе не создаёт режим коммерческой тайны.

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

Поэтому система должна сохранять:

• исходную классификацию документа;
• владельца информации;
• список разрешённых групп;
• историю обращений;
• ссылки на оригинальные файлы;
• изменения прав доступа.

RAG не должен превращаться в обход действующих правил документооборота.

Как устроен локальный RAG

Базовая архитектура включает два независимых конвейера:

и

Ниже поэтапно объясняем, как работает RAG.

Этап 1. Подключение источников

Система получает документы из утверждённых хранилищ.

Не стоит начинать с копирования всего корпоративного диска. Для пилота лучше выбрать один контролируемый источник, например:

• действующие инструкции отдела;
• документацию одного проекта;
• базу закрытых инцидентов;
• комплект эксплуатационных регламентов.

Команда должна понимать, кто отвечает за каждый источник и как система узнаёт об изменениях.

Этап 2. Извлечение содержимого

Текстовые PDF и DOCX обычно обрабатываются напрямую. Сканам потребуется оптическое распознавание текста — OCR. Подробнее про эту технологию мы рассказывали в этом материале.

Сложнее всего извлекать:

• таблицы;
• многоуровневые списки;
• подписи к рисункам;
• формулы;
• колонтитулы;
• чертежи;
• текст внутри изображений;
• связи между разделами.

Если обработчик разрушит структуру документа, языковая модель получит набор строк без контекста.

Этап 3. Очистка и метаданные

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

К каждому фрагменту нужно добавить метаданные:

• название файла;
• путь к оригиналу;
• проект;
• раздел;
• номер страницы;
• дату;
• версию;
• статус;
• автора;
• подразделение;
• права доступа.

Метаданные позволяют не только найти ответ, но и объяснить, откуда он взялся.

Этап 4. Разделение на смысловые фрагменты

Модель не должна каждый раз читать документ целиком. Система делит его на небольшие логические части.

Слишком короткие фрагменты теряют контекст. Слишком длинные добавляют лишний текст и ухудшают точность поиска.

Для разных материалов нужны разные правила:

• регламент делят по разделам и пунктам;
• договор — по условиям;
• технический отчёт — по главам;
• таблицу стараются сохранить целиком;
• исходный код делят по функциям и классам.

Универсального размера фрагмента для всех документов не существует. Его нужно подобрать на контрольной выборке.

Этап 5. Создание векторных представлений

Модель векторизации преобразует каждый фрагмент в набор чисел. Тексты с близким смыслом получают близкие векторы.

Для русскоязычной и смешанной документации можно тестировать BGE-M3 или семейство Qwen3 Embedding. BGE-M3 поддерживает более 100 языков, длинные тексты до 8192 токенов и несколько режимов поиска. Qwen3 Embedding выпускается в версиях от 0,6 до 8 млрд параметров, поддерживает более 100 языков и контекст до 32 тысяч токенов.

Выбирать модель только по публичному рейтингу нельзя. Команда должна проверить её на собственных терминах, сокращениях, артикулах и русскоязычных запросах.

Ollama предоставляет локальный интерфейс для создания векторных представлений и отдельно рекомендует использовать одну и ту же модель при индексировании документов и обработке запросов.

Этап 6. Запись в векторную базу

Векторная база хранит числовые представления (эмбеддинги), текст фрагментов и метаданные.

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

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

Этап 7. Поиск кандидатов

Когда сотрудник задаёт вопрос, система:

1. проверяет его учётную запись;
2. определяет разрешённые источники;
3. создаёт вектор запроса;
4. выполняет смысловой и точный поиск;
5. отбирает несколько десятков кандидатов.

Чем шире первый поиск, тем выше шанс найти нужный фрагмент, но тем больше времени займёт следующая стадия.

Этап 8. Повторное ранжирование

Модель повторного ранжирования получает вопрос и найденные фрагменты, затем пересортировывает их по релевантности.

Например, первоначальный поиск может найти десять документов со словами «контроль качества». Повторное ранжирование поднимет выше тот, который действительно отвечает на вопрос о конкретной процедуре испытаний.

Для этого можно использовать модели Qwen3 Reranker или BGE Reranker. Семейство Qwen3 Reranker включает варианты на 0,6, 4 и 8 млрд параметров; младшая версия снижает требования к ресурсам, а старшие рассчитаны на более сложное ранжирование.

Повторное ранжирование повышает качество, но добавляет задержку. Для небольшого пилота можно начать без него, измерить ошибки, а затем добавить этот этап.

Этап 9. Генерация ответа

Языковая модель получает:

• вопрос сотрудника;
• найденные фрагменты;
• системные правила;
• требования к формату;
• инструкцию указывать источники.

Для первого проекта можно тестировать Qwen3 14B, Gemma 3 12B или gpt-oss-20b. OpenAI указывает, что gpt-oss-20b в оптимизированном формате способен работать при 16 ГБ памяти, поэтому модель подходит для локальных экспериментов без серверного ускорителя высшего класса.

Самая крупная доступная модель не всегда даст лучший корпоративный поиск. На качество сильнее могут повлиять:

• актуальность документов;
• корректные права доступа;
• точный поиск;
• структура фрагментов;
• повторное ранжирование;
• правила отказа от ответа.

Этап 10. Ответ со ссылками

Хороший ИИ-ассистент по документам должен показывать:

• краткий ответ;
• название источника;
• номер раздела или страницы;
• версию документа;
• ссылку на оригинал;
• предупреждение о противоречиях.

Когда найденных данных недостаточно, система должна написать:

Такой ответ полезнее уверенной выдумки.

Как выглядит практический стек

Один из вариантов локального контура:

Это пример, а не обязательный набор. Компания может заменить каждый компонент, если сохранит общую архитектуру и требования к безопасности.

Пошаговый план внедрения

Шаг 1. Определите конкретный сценарий

Плохая постановка: Сделать ИИ по документам компании.

Хорошая постановка: Ассистент отвечает инженерам по действующим регламентам испытаний, показывает источник и отказывается отвечать по архивным версиям.

Во втором варианте команда понимает, какие документы индексировать и как проверить результат.

Шаг 2. Соберите реальные вопросы

Попросите сотрудников записать 100–300 вопросов, которые они регулярно задают коллегам или пытаются найти в документации.

Добавьте сложные случаи:

• вопрос с точным номером;
• вопрос другими словами;
• вопрос, на который нет ответа;
• вопрос по устаревшей версии;
• вопрос с ограниченным доступом;
• вопрос, который требует двух документов.

Эта выборка станет основой тестирования.

Шаг 3. Проведите аудит документов

Проверьте:

• актуальность;
• наличие владельца;
• версии;
• дубликаты;
• качество сканов;
• права доступа;
• заполненность метаданных;
• архивные материалы.

RAG не исправит хаос в документации. Он сделает этот хаос доступным через чат.

Шаг 4. Запустите пилот на одном источнике

Не подключайте сразу все сетевые диски.

Для начала выберите:

• один отдел;
• один тип документов;
• одну группу пользователей;
• один измеримый сценарий.

Так команда быстрее найдёт ошибки в извлечении, поиске и доступах.

Шаг 5. Настройте индексирование

Определите:

• как система делит документы;
• какую модель векторизации использует;
• как часто проверяет обновления;
• что делает с удалёнными файлами;
• как обрабатывает новую версию;
• как связывает фрагмент с оригиналом.

При удалении документа нужно удалить и его фрагменты из поискового индекса.

Шаг 6. Настройте гибридный поиск

Смысловой поиск отвечает на вопросы обычным языком. Точный поиск находит номера, коды и термины.

Для технической документации чаще всего нужны оба.

Шаг 7. Добавьте правила ответа

Системная инструкция должна требовать:

• опираться только на найденные материалы;
• указывать источники;
• не заменять точные значения предположениями;
• сообщать о нехватке данных;
• выделять противоречащие документы;
• учитывать дату и статус версии.

Шаг 8. Подключите корпоративную авторизацию

Пользователь должен видеть только те документы, к которым имеет доступ в исходной системе.

Не стоит загружать весь индекс в контекст модели, а затем просить её «не показывать секретное». Модель не является механизмом разграничения доступа.

Шаг 9. Проведите закрытое тестирование

Выдайте систему небольшой группе сотрудников и фиксируйте:

• вопросы;
• найденные источники;
• оценку ответа;
• пропущенные документы;
• ошибочные ссылки;
• время ответа;
• случаи отказа.

Шаг 10. Переведите систему в эксплуатацию

Перед общим запуском настройте:

• резервное копирование;
• мониторинг;
• журналы;
• обновление индекса;
• удаление данных;
• контроль доступа;
• план восстановления;
• тестовую среду для обновлений.

Как оценивать качество RAG

Не измеряйте систему только по тому, насколько убедительно она разговаривает.

Качество поиска

Проверьте, попал ли нужный фрагмент в первые результаты.

Если модель не получила правильный источник, она не сможет сформировать надёжный ответ.

Точность цитат

Источник должен действительно подтверждать написанное, а ссылка — вести на правильную версию и раздел.

Доля обоснованных ответов

Проверьте, опирается ли каждое существенное утверждение на найденный контекст.

Правильный отказ

Система должна отказываться, когда база не содержит ответа или пользователь не имеет доступа.

Скорость

Измеряйте отдельно:

• поиск;
• повторное ранжирование;
• начало генерации;
• полный ответ.

Польза для сотрудника

Главный вопрос: «Помог ли ассистент решить задачу быстрее, чем обычный поиск и обращение к коллеге?».

Как защитить локальную базу знаний с ИИ

Наследуйте права из исходных систем

Не создавайте одну общую коллекцию без меток доступа.

Каждый фрагмент должен знать, кто может его получить.

Разделяйте документы и инструкции

Документ может содержать текст, который пытается управлять поведением модели: например, «игнорируй предыдущие правила».

OWASP относит такие атаки к косвенному внедрению инструкций и отдельно предупреждает о вредоносном содержимом в базах RAG. Сам RAG не устраняет эту уязвимость.

Система должна считать найденный текст данными, а не доверенной командой.

Не подключайте инструменты без необходимости

Поиск-ассистенту обычно достаточно читать документы. Ему не нужно самостоятельно удалять файлы, менять права или отправлять конфиденциальные данные.

Ведите журналы

Записывайте:

• пользователя;
• время;
• запрос;
• источники;
• модель;
• версию индекса;
• ответ;
• ошибки;
• изменения прав.

Журналы тоже могут содержать персональные и конфиденциальные данные, поэтому для них нужны отдельные сроки хранения и права доступа.

Защищайте резервные копии

Зашифруйте копии, отделите их от рабочего сервера и регулярно проверяйте восстановление.

Контролируйте загрузку новых файлов

Не разрешайте любому пользователю бесконтрольно добавлять документы в общую базу. Иначе ошибочный или вредоносный файл повлияет на ответы всей команды.

Какое оборудование нужно

Основную видеопамять обычно потребляет языковая модель. Модель векторизации и повторное ранжирование можно запускать на той же GPU, отдельной карте или процессоре — выбор зависит от потока запросов.

Векторная база сильнее зависит от оперативной памяти, NVMe-накопителей и объёма индекса.

Уровень 1. Пилот и один отдел

Для пилота, разработки и работы небольшой команды подойдёт Performance Pro 350R.

Платформа поддерживает одну видеокарту от RTX 5060 Ti до RTX PRO 6000 Blackwell, до 96 ГБ видеопамяти и до 128 ГБ оперативной памяти.

Практичная конфигурация для старта:

• GPU с 16–32 ГБ видеопамяти;
• 64–128 ГБ ОЗУ;
• NVMe от 2 ТБ;
• отдельное резервное хранилище;
• сеть от 2,5 Гбит/с при работе с сетевыми источниками.

Когда хватит 16 ГБ. Такой объём подходит для пилота с компактной языковой моделью, небольшой группой пользователей и умеренным контекстом. Например, gpt-oss-20b в оптимизированном формате рассчитана на системы с 16 ГБ памяти.

Когда выбрать 32 ГБ. 32 ГБ дают больше свободы при выборе моделей, длины контекста и одновременной работе нескольких компонентов.

Когда нужна RTX PRO 6000 96 ГБ. Её стоит рассматривать для крупных моделей, длинного контекста, нескольких сервисов или запаса под развитие системы без перехода к нескольким GPU.

Уровень 2. Несколько отделов и две GPU

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

• первая GPU запускает языковую модель;
• вторая обслуживает модель векторизации, повторное ранжирование или дополнительный экземпляр LLM.

Для такого сценария подходит Performance Pro 750R. Станция поддерживает две GPU, до 192 ГБ суммарной видеопамяти и до 1 ТБ оперативной памяти ECC.

Performance Pro 750R стоит рассматривать, если:

• одной GPU уже мало;
• система обслуживает несколько команд;
• нужен большой объём оперативной памяти;
• компания хочет совместить промышленный сервис и тестовую среду;
• RAG использует крупную модель или несколько индексов.

[ PERFORMANCE PRO RACK ]

350R RACK

U9-285K · RTX 5090 32ГБ · 128GB DDR5 RGB · 2 ТБ

1 271 500 ₽

95 363 ₽ / мес Примерный ежемесячный платёж. Итоговая сумма рассчитывается индивидуально.

Подробнее

750R RACK

7975WX · RTX 5090 32ГБ · 256GB DDR5 ECC · 2 ТБ NVMe 5.0

3 574 000 ₽

268 050 ₽ / мес Примерный ежемесячный платёж. Итоговая сумма рассчитывается индивидуально.

Подробнее

900R RACK

2 x EPYC 9575F · RTX PRO 5000 48GB · 512GB DDR5 ECC · 2 ТБ

6 694 000 ₽

502 050 ₽ / мес Примерный ежемесячный платёж. Итоговая сумма рассчитывается индивидуально.

Подробнее

Уровень 3. Корпоративный сервис на Devbox AI

DEVBOX AI подходит для централизованного RAG-сервиса, который работает круглосуточно и обслуживает несколько отделов или юридических лиц.

Платформа поддерживает до четырёх RTX 5090 или до шести профессиональных ускорителей, накопители NVMe PCIe 5.0, два сетевых интерфейса 10 Гбит/с и резервируемые блоки питания.

Несколько GPU позволяют:

• запустить отдельные экземпляры модели для разных отделов;
• разделить поиск, повторное ранжирование и генерацию;
• обслуживать больше параллельных запросов;
• тестировать новую модель, не останавливая рабочую;
• изолировать сервисы с разными требованиями.

Devbox AI не нужен только потому, что в компании много документов. Размер архива в первую очередь влияет на хранилище и индекс. Многопроцессорный GPU-сервер оправдывает число пользователей, размер моделей, параллельность и требования к доступности.

Для каких задач Компактный GPU-сервер до 2 видеокарт для начальных задач в AI и графике. Оптимален для инференса, визуализации, VFX и рендеринга в студиях и лабораториях, где важна гибкость.

Подробнее

Видеокарты

RTX / RTX PRO / H200 NVL

Объем видеопамяти до 282 ГБ

Процессоры

Threadripper PRO

Количество ядер до 96

RAM до 1024 ГБ DDR5

Форм-фактор 4.5U

Для каких задач Универсальная платформа на 4–6 GPU для локального обучения моделей и генеративных задач. Подходит для команд, которым важна надёжность сервера и свобода выбора графики — от RTX 5090 до PRO RTX 6000.

Подробнее

Видеокарты

RTX / RTX PRO / H200 NVL

Объем видеопамяти до 576 ГБ

Процессоры

Threadripper PRO

Количество ядер до 96

RAM до 1024 ГБ DDR5

Форм-фактор 6.5U

Для каких задач Сервер промышленного уровня на 8 GPU с кластерной архитектурой. Предназначен для дата-центров и AI-ферм, где требуется масштабируемость и полная загрузка ресурсов под обучение LLM и R&D.

Подробнее

Видеокарты

RTX PRO 6000 / RTX 5090

Объем видеопамяти до 768 ГБ

Процессоры

AMD Epyc, Intel Xeon

Количество ядер до 320

RAM до 3072 ГБ DDR5

Форм-фактор 6U

OneStack для быстрого запуска RAG

Рабочие станции и серверы DigitalRazor серий AI могут поставляться с предустановленной платформой OneStack.

OneStack включает подготовленное программное окружение, управление контейнерами и мониторинг ресурсов. Среди заявленных сценариев платформы есть корпоративный чат и умный поиск RAG по внутренней документации. Платформа также поддерживает работу в изолированном контуре без интернета.

Это сокращает время на установку:

• Linux;
• драйверов NVIDIA;
• CUDA;
• Docker;
• интерфейса;
• моделей;
• контейнеров баз данных.

OneStack не исправляет документы и не проектирует правила доступа автоматически. Команде всё равно нужно подготовить источники, контрольную выборку и схему безопасности.

Как выбрать между станцией и Devbox AI

Окончательный выбор нужно делать после пилота и нагрузочного тестирования.

Экономика локального RAG

Экономический эффект создаёт не сама нейросеть, а сокращение времени на поиск и повторные консультации.

Пример расчёта:

• системой пользуются 40 сотрудников;
• каждый тратит на поиск документов 20 минут в день;
• локальный RAG сокращает это время на 30%;
• полная стоимость часа сотрудника — 1000 рублей;
• в месяце 22 рабочих дня.

Исходные затраты времени:

Потенциально высвобожденное время:

Условный экономический эффект:

Это иллюстративный расчёт. Реальный эффект зависит от качества документов, профессии сотрудников и того, используют ли они сэкономленное время для полезной работы.

В проект также нужно включить:

• оборудование;
• внедрение;
• интеграции;
• подготовку документов;
• безопасность;
• сопровождение;
• резервное копирование;
• обучение пользователей.

Типичные ошибки

Подключить все документы сразу. Команда теряет контроль над версиями, правами и качеством.

Выбрать самую крупную модель. Большая модель не исправит плохой поиск и неактуальные источники.

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

Не показывать источники. Сотрудник не может проверить ответ и начинает воспринимать модель как справочник.

Смешать права доступа. Ассистент выдаёт фрагменты из документов, которые пользователь не должен видеть.

Индексировать устаревшие версии без статуса. Модель находит отменённый регламент и формирует по нему убедительный ответ.

Не тестировать отказ. Система отвечает даже тогда, когда в документах нет нужной информации.

Открыть систему в интернет. Интерфейс, векторная база и сервер модели должны находиться в защищённой сети или за контролируемым шлюзом.

Чек-лист перед запуском

• Команда выбрала один измеримый сценарий.
• У каждого источника есть владелец.
• Документы имеют версии и статусы.
• Система сохраняет ссылки на оригиналы.
• Права доступа действуют до выполнения поиска.
• Команда подготовила контрольные вопросы.
• Ассистент умеет отказываться от ответа.
• Ответы содержат источники.
• Обновление индекса работает автоматически.
• Удалённые документы исчезают из выдачи.
• Система ведёт журналы.
• Резервные копии проходят проверку восстановления.
• ИТ-команда контролирует версии моделей.
• Специалист по безопасности проверил угрозы.
• Юрист оценил обработку персональных данных и режим коммерческой тайны.

FAQ

Заключение

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

Начинать нужно не с покупки самого дорогого GPU-сервера. Сначала выберите один отдел, подготовьте действующие документы, соберите контрольные вопросы и проверьте качество поиска.

Для пилота или одной команды подойдёт Performance Pro 350R с одной GPU. При росте модели и нагрузки можно перейти к Performance Pro 750R с двумя ускорителями.

Для централизованного сервиса нескольких отделов стоит рассмотреть DEVBOX AI: платформа поддерживает несколько GPU, быстрые NVMe-накопители, сеть 10 Гбит/с и круглосуточную эксплуатацию.

Инструмент OneStack помогает быстрее развернуть локальную модель, интерфейс и RAG без ручной настройки всего программного окружения.

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

Для каких задач Серия серверов для кластеризации на 4 GPU. Предназначены для дата-центров и AI-ферм, где требуется повышенная плотность для обучение LLM и R&D.

Подробнее

Видеокарты

L40s / RTX PRO / H200 NVL

Объем видеопамяти до 564 ГБ

Процессоры

AMD EPYC, Intel Xeon

Количество ядер до 128

RAM до 1536 ГБ DDR5

Форм-фактор 2U

Для каких задач Серия серверов для кластеризации на 8 GPU. Предназначены для дата-центров и AI-ферм, где требуется повышенная плотность для обучение LLM и R&D.

Подробнее

Видеокарты

L40s / RTX PRO / H200 NVL

Объем видеопамяти до 1128 ГБ

Процессоры

AMD EPYC, Intel Xeon

Количество ядер до 256

RAM до 2048 ГБ DDR5

Форм-фактор 4U

Для каких задач HGX объединяет 8 видеокарт NVIDIA H200, достигая экстремальной плотности производительности. Благодаря внутренней связности NVSwitch мгновенно интегрируется в масштабные вычислительные кластеры.

Подробнее

Видеокарты

NVIDIA H200 SXM

Объем видеопамяти до 1128 ГБ

Процессоры

AMD EPYC, Intel Xeon

Количество ядер до 256

RAM до 2048 ГБ DDR5

Форм-фактор 5U