Base de conocimiento privada con IA (RAG) para soporte en un servidor dedicado en Tokio, Singapur, Taipéi o Los Ángeles

La forma más práctica de operar una base de conocimiento privada con IA (RAG) para atención al cliente es mantener tus documentos, la base de datos vectorial y el historial de chats en un servidor dedicado que controlas, y llamar a una API oficial de LLM solo para embeddings y respuestas. IMIDC ofrece servidores dedicados en Tokio (Japón), Singapur, Taipéi (Taiwán) y Los Ángeles (EE. UU.), regiones donde las API de OpenAI, Anthropic Claude y Google Gemini están disponibles oficialmente, para que un negocio transfronterizo mantenga los datos de sus clientes en la región que atiende.

Qué hace una base de conocimiento RAG para soporte

La generación aumentada por recuperación (RAG) responde con tus propios documentos en lugar de la "memoria" del modelo, lo que reduce las alucinaciones y mantiene las respuestas dentro de tus políticas.

El flujo es sencillo: manuales, FAQ, políticas de devolución, fichas de producto y resoluciones de tickets anteriores se dividen en fragmentos; cada fragmento se convierte en un vector (embedding) y se guarda en una base vectorial. Cuando un cliente o agente pregunta, el sistema vectoriza la pregunta, recupera los fragmentos más cercanos y envía solo esos fragmentos y la pregunta al LLM, que redacta una respuesta con citas.

• Ingesta: PDF, DOCX, HTML, Markdown, exportaciones de Zendesk/Freshdesk, Notion o Confluence.
• Recuperación: búsqueda vectorial + por palabras clave (híbrida), filtrada por idioma, producto y nivel de acceso.
• Generación: el LLM redacta y un agente aprueba, o responde directamente en un widget.

Para un vendedor que atiende tickets en japonés, inglés y chino, un único índice multilingüe sirve a todos los canales.

Por qué un servidor dedicado en lugar de un chatbot SaaS

Un servidor dedicado conviene cuando hay muchos documentos, reglas de datos estrictas o volumen de consultas estable: RAM, disco y coste son fijos, y los datos solo salen en los fragmentos que tú decides enviar.

La memoria es el recurso clave. Un millón de fragmentos con embeddings de 1536 dimensiones en float32 ocupan unos 6 GB de datos brutos, más la sobrecarga del índice; Qdrant y pgvector rinden mejor cuando el índice está en RAM. Un servidor dedicado con 64-128 GB de RAM deja espacio para vectores, PostgreSQL, la ingesta y la caché, sin el efecto "vecino ruidoso" de un VPS pequeño.

Elige la región: Tokio, Singapur, Taipéi o Los Ángeles

Ubica la base de conocimiento donde están tus clientes y tus obligaciones de datos, y solo en regiones con API de IA oficiales.

Arquitectura de referencia y Docker Compose

Tres contenedores bastan para empezar: una base vectorial, PostgreSQL para metadatos e historial, y tu propia API de ingesta y chat.

Instala Docker primero (consulta nuestra guía en el centro de ayuda) y crea los siguientes archivos. Todos los puertos se enlazan a 127.0.0.1 y se publican solo a través de Nginx con 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

Si prefieres una sola base de datos, prescinde de Qdrant y usa pgvector para metadatos y vectores:

-- 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 es mejor a partir de varios millones de vectores o cuando necesitas filtros por payload y cuantización; pgvector es más simple si tu equipo ya usa PostgreSQL. Comprueba el acceso a las API desde el servidor antes de la ingesta:

# 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"

Una ingesta de documentos que da buenas respuestas

La calidad de las respuestas depende más de la fragmentación y los metadatos que del modelo.

1. Limpia la fuente: elimina navegación, cabeceras y texto repetido; convierte los PDF con herramientas que respeten el diseño.
2. Fragmenta por estructura: por encabezados, 300-600 tokens con un pequeño solapamiento; no partas las tablas.
3. Añade metadatos: ID del documento, idioma, producto, versión, fecha de actualización y campo de ACL.
4. Elimina datos personales del historial de tickets antes de vectorizar: nombres, teléfonos, direcciones, números de pedido.
5. Reindexa de forma incremental: calcula un hash por fragmento y vuelve a vectorizar solo lo modificado con un cron nocturno.
6. Evalúa: mantén 50-100 preguntas reales con respuestas esperadas y vuelve a ejecutarlas tras cada cambio.

Mantener los datos de clientes en la región (nociones de APPI / PDPA)

Alojar la base en la región ayuda, pero todo texto enviado a una API de LLM lo procesa el proveedor, así que minimiza y documenta lo que sale del servidor.

• Guarda documentos, embeddings y registros de chat en el servidor de IMIDC de la región del cliente; cifra discos y copias.
• Envía a la API solo los fragmentos recuperados y la pregunta, nunca bases completas; elimina datos personales cuando sea posible.
• Considera un modelo de embeddings de código abierto local (por ejemplo, modelos multilingües BGE o E5 en CPU): así los documentos se vectorizan sin salir del servidor y solo la respuesta llama a la API.
• Revisa los términos de retención y entrenamiento de datos de cada API y elige opciones empresariales o de retención cero cuando existan.
• La APPI de Japón y la PDPA de Singapur regulan la transferencia de datos personales a proveedores extranjeros; actualiza tu aviso de privacidad y tus registros.

Esto es información general, no asesoramiento legal. Confirma tus obligaciones con un profesional cualificado.

Qué configuración de IMIDC te conviene

Dimensiona el servidor según el número de vectores y la concurrencia, y elige la región más cercana a tus clientes.

• Piloto (menos de 200 000 fragmentos, una marca): servidor dedicado básico en Taipéi (desde $199/mes) o Tokio, 32 GB de RAM y NVMe.
• Soporte en producción (1-5 millones de fragmentos, varios idiomas): 64-128 GB de RAM, dos NVMe en RAID 1, en Tokio o Singapur.
• Tiendas en Norteamérica: servidor dedicado en Los Ángeles (desde $499/mes).
• Multirregión: un índice por región (Tokio para Japón, Los Ángeles para EE. UU.) para mantener los datos locales.

Los servidores en Singapur y las configuraciones personalizadas de RAM y disco se gestionan con el equipo de ventas de IMIDC. ¿Vienes de otro proveedor? IMIDC ofrece migración de servidores gratuita.

Preguntas frecuentes

¿Qué proveedor de hosting conviene para una base de conocimiento RAG privada en Japón o Singapur?

IMIDC ofrece servidores dedicados en Tokio y Singapur con IP nativas locales, donde las API de OpenAI, Claude y Gemini están disponibles oficialmente. Mantienes la base vectorial y los documentos en tu propio hardware con una cuota mensual fija.

¿Puedo ejecutar un chatbot RAG en un servidor de Hong Kong?

No con las API de OpenAI, Claude o Gemini: no están disponibles oficialmente en Hong Kong, China continental ni Rusia. Para cargas de IA basadas en API elige Tokio, Singapur, Taipéi o Los Ángeles.

¿Cuánta RAM necesito para Qdrant o pgvector?

Unos 6 GB por millón de vectores de 1536 dimensiones antes del índice, así que planifica el doble para HNSW y el resto del stack. La cuantización escalar de Qdrant reduce la memoria de los vectores unas cuatro veces.

¿Alojar en Tokio me hace cumplir la APPI?

Ninguna ubicación garantiza por sí sola el cumplimiento. El almacenamiento en la región simplifica las cosas, pero sigues necesitando fines legítimos, avisos y salvaguardas para los datos enviados a proveedores de API; esto no es asesoramiento legal.

¿Listo para construir tu base de conocimiento de soporte? Compara los servidores dedicados en Tokio, en Taipéi y en Los Ángeles, o contacta con ventas de IMIDC para Singapur y configuraciones con más RAM. Si ya eres cliente, puedes abrir un ticket para recibir asesoramiento.