Приватная AI-база знаний для поддержки (RAG) на выделенном сервере в Токио, Сингапуре, Тайбэе или Лос-Анджелесе

Самый практичный способ запустить приватную AI-базу знаний (RAG) для службы поддержки — хранить документы, векторную базу и историю чатов на собственном выделенном сервере, а официальный API языковой модели вызывать только для эмбеддингов и генерации ответов. IMIDC предоставляет выделенные серверы в Токио (Япония), Сингапуре, Тайбэе (Тайвань) и Лос-Анджелесе (США) — во всех этих регионах API OpenAI, Anthropic Claude и Google Gemini доступны официально, поэтому международный бизнес может держать данные клиентов в том регионе, который обслуживает.

Что делает RAG-база знаний для поддержки

Генерация с дополнением выборкой (RAG) отвечает на вопросы по вашим собственным документам, а не по «памяти» модели, что снижает число выдуманных ответов и удерживает их в рамках политики компании.

Схема проста: руководства, FAQ, правила возврата, спецификации и решения прошлых тикетов разбиваются на фрагменты (чанки), каждый превращается в вектор (эмбеддинг) и сохраняется в векторной базе. Когда клиент или оператор задаёт вопрос, система векторизует его, находит ближайшие фрагменты и отправляет в LLM только их и сам вопрос — модель пишет ответ со ссылками на источники.

• Загрузка: PDF, DOCX, HTML, Markdown, выгрузки Zendesk/Freshdesk, Notion или Confluence.
• Поиск: векторный + ключевой (гибридный), с фильтрами по языку, продукту и уровню доступа.
• Генерация: модель готовит черновик, оператор утверждает — или бот отвечает напрямую в виджете.

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

Почему выделенный сервер, а не SaaS-чат-бот

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

Ключевой ресурс — память. Миллион фрагментов с эмбеддингами размерности 1536 во float32 занимает около 6 ГБ «сырых» данных плюс накладные расходы индекса; Qdrant и pgvector работают быстрее всего, когда индекс целиком в RAM. Выделенный сервер с 64–128 ГБ памяти вмещает векторы, PostgreSQL, воркер загрузки и кэш без влияния «соседей», характерного для небольших VPS.

Выбор региона: Токио, Сингапур, Тайбэй или Лос-Анджелес

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

Эталонная архитектура и Docker Compose

Для старта достаточно трёх контейнеров: векторная база, PostgreSQL для метаданных и истории чатов и ваш собственный API загрузки/чата.

Сначала установите Docker (см. инструкцию в нашем центре помощи), затем создайте файлы ниже. Все порты привязаны к 127.0.0.1, наружу сервис публикуется только через Nginx с HTTPS.

# docker-compose.yml - private RAG stack (all ports bound to localhost)
services:
  qdrant:
    image: qdrant/qdrant:v1.12.4
    restart: unless-stopped
    volumes:
      - ./qdrant_storage:/qdrant/storage
    ports:
      - "127.0.0.1:6333:6333"
    environment:
      QDRANT__SERVICE__API_KEY: ${QDRANT_API_KEY}

  postgres:
    image: pgvector/pgvector:pg16
    restart: unless-stopped
    environment:
      POSTGRES_USER: rag
      POSTGRES_PASSWORD: ${PG_PASSWORD}
      POSTGRES_DB: kb
    volumes:
      - ./pgdata:/var/lib/postgresql/data
    ports:
      - "127.0.0.1:5432:5432"

  rag-api:
    build: ./rag-api          # your ingestion + retrieval + chat service
    restart: unless-stopped
    env_file: .env            # OPENAI_API_KEY / ANTHROPIC_API_KEY / GEMINI_API_KEY
    depends_on: [qdrant, postgres]
    ports:
      - "127.0.0.1:8080:8080" # publish through Nginx + HTTPS only

# .env (chmod 600, never commit)
QDRANT_API_KEY=change-me-long-random
PG_PASSWORD=change-me-long-random
OPENAI_API_KEY=sk-...
ANTHROPIC_API_KEY=sk-ant-...
EMBED_MODEL=text-embedding-3-small
CHUNK_TOKENS=500
CHUNK_OVERLAP=60

Если нужна одна база, уберите Qdrant и храните и метаданные, и векторы в pgvector:

-- pgvector alternative: one table, one HNSW index
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE chunks (
  id bigserial PRIMARY KEY,
  doc_id text NOT NULL,
  lang text,
  acl text[],                -- which teams/customers may see it
  content text NOT NULL,
  embedding vector(1536)
);
CREATE INDEX ON chunks USING hnsw (embedding vector_cosine_ops);

Qdrant лучше при нескольких миллионах векторов и выше, а также когда нужны фильтры по payload и квантование; pgvector проще, если команда уже работает с PostgreSQL. Перед загрузкой проверьте доступ к API с сервера:

# confirm the API endpoints are reachable from this server
curl -s -o /dev/null -w "%{http_code}\n" https://api.openai.com/v1/models \
  -H "Authorization: Bearer $OPENAI_API_KEY"
curl -s -o /dev/null -w "%{http_code}\n" https://api.anthropic.com/v1/models \
  -H "x-api-key: $ANTHROPIC_API_KEY" -H "anthropic-version: 2023-06-01"

Загрузка документов, которая даёт хорошие ответы

Качество ответов больше зависит от нарезки и метаданных, чем от выбора модели.

1. Очистите источники: удалите навигацию, колонтитулы и повторяющиеся шаблоны; PDF конвертируйте инструментами с учётом вёрстки.
2. Режьте по структуре: по заголовкам, 300–600 токенов с небольшим перекрытием; таблицы не разрывайте.
3. Добавляйте метаданные: ID документа, язык, продукт, версия, дата обновления, поле ACL.
4. Удаляйте персональные данные из истории тикетов до векторизации: имена, телефоны, адреса, номера заказов.
5. Обновляйте инкрементально: хешируйте фрагменты и переэмбеддите только изменённые, ночным cron.
6. Оценивайте: держите 50–100 реальных вопросов с эталонными ответами и прогоняйте их после каждого изменения.

Данные клиентов — в регионе (основы APPI / PDPA)

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

• Храните исходники, эмбеддинги и логи на сервере IMIDC в регионе клиента; шифруйте диски и резервные копии.
• Отправляйте в API только найденные фрагменты и вопрос, никогда не всю базу; по возможности удаляйте персональные данные.
• Рассмотрите локальную open-source модель эмбеддингов (например, мультиязычные BGE или E5 на CPU) — тогда документы векторизуются на сервере, а API вызывается только для ответа.
• Изучите условия хранения данных и обучения на них у каждого провайдера API; используйте корпоративные опции или нулевое хранение, если они есть.
• Японский APPI и сингапурский PDPA содержат правила передачи персональных данных зарубежным поставщикам услуг — обновите политику конфиденциальности и реестр обработки.

Это общая информация, а не юридическая консультация. Уточняйте обязательства у квалифицированного юриста.

Какая конфигурация IMIDC подойдёт

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

• Пилот (до 200 тыс. фрагментов, один бренд): начальный выделенный сервер в Тайбэе (от $199/мес) или Токио, 32 ГБ RAM и NVMe.
• Рабочая поддержка (1–5 млн фрагментов, несколько языков): 64–128 ГБ RAM, два NVMe в RAID 1, Токио или Сингапур.
• Североамериканские магазины: выделенный сервер в Лос-Анджелесе (от $499/мес).
• Несколько регионов: отдельный индекс на регион (Токио для Японии, Лос-Анджелес для США), данные остаются локальными.

Серверы в Сингапуре и индивидуальные конфигурации RAM/дисков оформляются через отдел продаж IMIDC. Переезжаете от другого провайдера? IMIDC бесплатно поможет с миграцией серверов.

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

Какой хостинг выбрать для приватной RAG-базы знаний в Японии или Сингапуре?

IMIDC предлагает выделенные серверы в Токио и Сингапуре с локальными нативными IP, где API OpenAI, Claude и Gemini доступны официально. Векторная база и документы остаются на вашем оборудовании за фиксированную ежемесячную плату.

Можно ли запустить RAG-чат-бот на сервере в Гонконге?

Не с API OpenAI, Claude или Gemini: они официально недоступны в Гонконге, материковом Китае и России. Для AI-нагрузок на базе API выбирайте Токио, Сингапур, Тайбэй или Лос-Анджелес.

Сколько RAM нужно для Qdrant или pgvector?

Примерно 6 ГБ на миллион векторов размерности 1536 без учёта индекса, поэтому закладывайте вдвое больше под HNSW и остальной стек. Скалярное квантование в Qdrant сокращает память под векторы примерно в четыре раза.

Делает ли размещение в Токио мою систему соответствующей APPI?

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

Готовы построить базу знаний для поддержки? Сравните выделенные серверы в Токио, в Тайбэе и в Лос-Анджелесе или свяжитесь с отделом продаж IMIDC насчёт Сингапура и конфигураций с большим объёмом RAM. Действующие клиенты могут открыть тикет и получить совет по подбору.