﻿# Chroma для RAG: локальная база и серверный режим

Chroma для RAG: in-memory и PersistentClient, отдельный сервер и HttpClient, embedding functions, сохранение данных, переход от notebook к совместному доступу.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/chroma-rag-hosting/
Language: ru

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

Описание проверено по официальным материалам 1 ноября 2026 года. Локальный notebook и совместно используемый сервис требуют разных эксплуатационных решений.

## Выберите режим хранения

[Chroma Clients](https://docs.trychroma.com/docs/run-chroma/clients) описывает варианты создания клиента. Для Python различаются экспериментальное состояние в памяти и `PersistentClient` с сохранением в указанном каталоге. Подключение к облачному сервису имеет другую границу размещения.

| Режим | Что нужно подтвердить |
| --- | --- |
| In-memory | Что потеря состояния после завершения допустима |
| PersistentClient | Правильный каталог и сохранение данных |
| Отдельный сервер | Адрес подключения, постоянное хранение и обслуживание |
| Облачный клиент | Применимые условия удалённого сервиса |

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

## Отделите клиент от сервера

[Client-Server Mode](https://docs.trychroma.com/docs/run-chroma/client-server) описывает отдельный процесс базы и HTTP-клиент. Это помогает нескольким приложениям обращаться к одному сервису, но добавляет сеть, управление процессом и план восстановления.

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

## Проверьте embedding function

[Embedding Functions](https://docs.trychroma.com/docs/embeddings/embedding-functions) описывает локальное вычисление и внешние API. Поэтому локальное хранение коллекции само по себе не доказывает, что тексты никогда не передаются внешнему сервису. Отдельно определите модель, зависимости и нужные сетевые обращения.

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

## Сохраните согласованность коллекции

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

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

## Измерьте сервер до расширения

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

Дальше читайте о [локальном RAG-сервере](/ru/journal/rag-server-local-architecture/) и [пакетных эмбеддингах](/ru/journal/text-embeddings-batch/).
