Home
Blog
¿Y si pudieras ver por qué falla RAG? Depuración de RAG en 3D con Project_Golem y Milvus

¿Y si pudieras ver por qué falla RAG? Depuración de RAG en 3D con Project_Golem y Milvus

Engineering

February 18, 2026

Min Yin

Cuando la recuperación RAG va mal, normalmente se sabe que está estropeada: no aparecen los documentos relevantes o aparecen los irrelevantes. Pero averiguar por qué es otra historia. Todo lo que tenemos para trabajar son puntuaciones de similitud y una lista plana de resultados. No hay forma de ver cómo se sitúan realmente los documentos en el espacio vectorial, cómo se relacionan los fragmentos entre sí o dónde aterrizó la consulta en relación con el contenido que debería haber coincidido. En la práctica, esto significa que la depuración de RAG se basa principalmente en el método de prueba y error: modificar la estrategia de agrupación, cambiar el modelo de incrustación, ajustar el top-k y esperar que los resultados mejoren.

Project_Golem es una herramienta de código abierto que hace visible el espacio vectorial. Utiliza UMAP para proyectar incrustaciones tridimensionales en 3D y Three.js para representarlas de forma interactiva en el navegador. En lugar de adivinar por qué falló la recuperación, se puede ver cómo se agrupan los trozos semánticamente, dónde aterriza la consulta y qué documentos se recuperaron, todo en una única interfaz visual.

Es asombroso. Sin embargo, el Project_Golem original se diseñó para pequeñas demostraciones, no para sistemas del mundo real. Se basa en archivos planos, búsquedas de fuerza bruta y reconstrucciones de conjuntos de datos completos, lo que significa que se rompe rápidamente cuando los datos crecen más allá de unos pocos miles de documentos.

Para llenar ese vacío, integramos Project_Golem con Milvus (concretamente la versión 2.6.8) como su columna vertebral vectorial. Milvus es una base de datos vectorial de alto rendimiento y código abierto que gestiona la ingesta en tiempo real, la indexación escalable y la recuperación a nivel de milisegundos, mientras que Project_Golem se centra en lo que mejor sabe hacer: hacer visible el comportamiento de la recuperación vectorial. Juntos, convierten la visualización 3D de una demostración de juguete en una herramienta de depuración práctica para los sistemas RAG de producción.

En este post, recorreremos Project_Golem y mostraremos cómo lo integramos con Milvus para hacer que el comportamiento de búsqueda de vectores sea observable, escalable y listo para la producción.

¿Qué es Project_Golem?

La depuración RAG es difícil por una sencilla razón: los espacios vectoriales son de alta dimensión, y los seres humanos no pueden verlos.

Project_Golem es una herramienta basada en navegador que le permite ver el espacio vectorial en el que opera su sistema RAG. Toma las incrustaciones de alta dimensión que impulsan la recuperación -normalmente 768 o 1536 dimensiones- y las proyecta en una escena 3D interactiva que puede explorar directamente.

He aquí cómo funciona:

Reducción de la dimensionalidad con UMAP. Project_Golem utiliza UMAP para comprimir vectores tridimensionales y reducirlos a tres dimensiones, conservando sus distancias relativas. Los trozos que son semánticamente similares en el espacio original permanecen juntos en la proyección 3D; los trozos no relacionados acaban muy separados.
Renderizado 3D con Three.js. Cada fragmento de documento aparece como un nodo en una escena 3D representada en el navegador. Puedes rotar, ampliar y explorar el espacio para ver cómo se agrupan tus documentos: qué temas se agrupan estrechamente, cuáles se solapan y dónde están los límites.
Resaltado en tiempo de consulta. Cuando se ejecuta una consulta, la recuperación sigue produciéndose en el espacio original de alta dimensión utilizando la similitud del coseno. Pero una vez que se obtienen los resultados, los fragmentos recuperados se iluminan en la vista 3D. De este modo, se puede ver inmediatamente dónde se ha situado la consulta en relación con los resultados y, lo que es igual de importante, en relación con los documentos que no se han recuperado.

Esto es lo que hace que Project_Golem sea útil para la depuración. En lugar de mirar una lista ordenada de resultados y adivinar por qué se ha omitido un documento relevante, puede ver si se encuentra en un clúster distante (un problema de incrustación), si se solapa con contenido irrelevante (un problema de agrupación) o si apenas se encuentra fuera del umbral de recuperación (un problema de configuración). La vista 3D convierte las puntuaciones abstractas de similitud en relaciones espaciales sobre las que se puede razonar.

Por qué Project_Golem no está listo para la producción

Project_Golem se diseñó como un prototipo de visualización, y funciona bien para eso. Pero su arquitectura hace suposiciones que se rompen rápidamente a escala - en formas que importan si desea utilizarlo para la depuración RAG en el mundo real.

Cada actualización requiere una reconstrucción completa

Esta es la limitación más fundamental. En el diseño original, la adición de nuevos documentos desencadena una reconstrucción completa de la tubería: las incrustaciones se regeneran y se escriben en archivos .npy, UMAP se vuelve a ejecutar en todo el conjunto de datos, y las coordenadas 3D se vuelven a exportar como JSON.

Incluso con 100.000 documentos, una ejecución de UMAP con un solo núcleo tarda entre 5 y 10 minutos. A escala de un millón de documentos, se vuelve totalmente impracticable. No se puede utilizar para ningún conjunto de datos que cambie continuamente - noticias, documentación, conversaciones de usuarios - porque cada actualización significa esperar un ciclo completo de reprocesamiento.

La búsqueda por fuerza bruta no es escalable

El lado de la recuperación tiene su propio techo. La implementación original utiliza NumPy para la búsqueda de similitud coseno por fuerza bruta: complejidad de tiempo lineal, sin indexación. En un conjunto de datos de un millón de documentos, una sola consulta puede tardar más de un segundo. Eso es inutilizable para cualquier sistema interactivo o en línea.

La presión de la memoria agrava el problema. Cada vector float32 de 768 dimensiones ocupa aproximadamente 3 KB, por lo que un conjunto de datos de un millón de vectores requiere más de 3 GB de memoria, todo ello cargado en una matriz NumPy plana sin estructura de índices que permita una búsqueda eficiente.

Sin filtrado de metadatos, sin multi-tenancy

En un sistema RAG real, la similitud vectorial rara vez es el único criterio de recuperación. Casi siempre es necesario filtrar por metadatos, como tipo de documento, marcas de tiempo, permisos de usuario o límites a nivel de aplicación. Un sistema RAG de atención al cliente, por ejemplo, necesita limitar la recuperación a los documentos de un inquilino específico, no buscar en los datos de todo el mundo.

Project_Golem no admite nada de esto. No hay índices RNA (como HNSW o IVF), ni filtrado escalar, ni aislamiento de inquilinos, ni búsqueda híbrida. Es una capa de visualización sin un motor de recuperación de producción por debajo.

Cómo Milvus potencia la capa de recuperación de Project_Golem

En la sección anterior se identificaron tres lagunas: reconstrucciones completas en cada actualización, búsqueda de fuerza bruta y ausencia de recuperación de metadatos. Las tres se deben a la misma causa: Project_Golem no tiene capa de base de datos. La recuperación, el almacenamiento y la visualización están enredados en una sola tubería, por lo que cambiar cualquier parte obliga a reconstruirlo todo.

La solución no consiste en optimizar ese proceso. Es separarlo.

Al integrar Milvus 2.6.8 como columna vertebral de los vectores, la recuperación se convierte en una capa dedicada de nivel de producción que funciona independientemente de la visualización. Milvus se encarga del almacenamiento, la indexación y la búsqueda de vectores. Project_Golem se centra exclusivamente en la representación, consumiendo los ID de los documentos de Milvus y resaltándolos en la vista 3D.

Esta separación produce dos flujos limpios e independientes:

Flujo de recuperación (en línea, a nivel de milisegundos)

Su consulta se convierte en un vector utilizando incrustaciones OpenAI.
El vector de consulta se envía a una colección Milvus.
Milvus AUTOINDEX selecciona y optimiza el índice apropiado.
Una búsqueda de similitud coseno en tiempo real devuelve los IDs de los documentos relevantes.

Flujo de visualización (fuera de línea, escala de demostración)

UMAP genera coordenadas 3D durante la ingestión de datos (n_neighbors=30, min_dist=0.1).
Las coordenadas se almacenan en golem_cortex.json.
El frontend resalta los nodos 3D correspondientes utilizando los ID de documento devueltos por Milvus.

El punto crítico: la recuperación ya no espera a la visualización. Puede ingerir nuevos documentos y buscarlos inmediatamente - la vista 3D se pone al día en su propio horario.

Qué cambian los nodos de streaming

Esta ingesta en tiempo real es impulsada por una nueva capacidad en Milvus 2.6.8: Streaming Nodes. En versiones anteriores, la ingesta en tiempo real requería una cola de mensajes externa como Kafka o Pulsar. Streaming Nodes traslada esa coordinación al propio Milvus: los nuevos vectores se ingieren continuamente, los índices se actualizan de forma incremental y los documentos recién añadidos se pueden buscar inmediatamente sin necesidad de una reconstrucción completa y sin dependencias externas.

Para Project_Golem, esto es lo que hace que la arquitectura sea práctica. Puede seguir añadiendo documentos a su sistema RAG - nuevos artículos, documentos actualizados, contenido generado por el usuario - y la recuperación se mantiene actualizada sin desencadenar el costoso ciclo UMAP → JSON → recarga.

Ampliación de la visualización a escala de millones (camino futuro)

Con esta configuración respaldada por Milvus, Project_Golem admite actualmente demostraciones interactivas de unos 10.000 documentos. La recuperación se escala mucho más allá de eso - Milvus maneja millones - pero la tubería de visualización todavía se basa en ejecuciones UMAP por lotes. Para colmar esta laguna, la arquitectura puede ampliarse con un proceso de visualización incremental:

Activadores de actualización: El sistema escucha los eventos de inserción en la colección Milvus. Una vez que los nuevos documentos añadidos alcanzan un umbral definido (por ejemplo, 1.000 elementos), se activa una actualización incremental.
Proyección incremental: En lugar de volver a ejecutar UMAP en todo el conjunto de datos, los nuevos vectores se proyectan en el espacio 3D existente utilizando el método transform() de UMAP. Esto preserva la estructura global a la vez que reduce drásticamente el coste computacional.
Sincronización frontend: Los fragmentos de coordenadas actualizados se transmiten al frontend a través de WebSocket, lo que permite que aparezcan nuevos nodos dinámicamente sin recargar toda la escena.

Más allá de la escalabilidad, Milvus 2.6.8 permite la búsqueda híbrida combinando la similitud vectorial con la búsqueda de texto completo y el filtrado escalar. Esto abre la puerta a interacciones 3D más ricas, como el resaltado de palabras clave, el filtrado de categorías y el troceado basado en el tiempo, lo que ofrece a los desarrolladores formas más potentes de explorar, depurar y razonar sobre el comportamiento RAG.

Cómo desplegar y explorar Project_Golem con Milvus

El Project_Golem actualizado es ahora de código abierto en GitHub. Utilizando la documentación oficial de Milvus como nuestro conjunto de datos, recorremos el proceso completo de visualización de la recuperación RAG en 3D. La configuración utiliza Docker y Python y es fácil de seguir, incluso si estás empezando desde cero.

Requisitos previos

Docker ≥ 20.10
Docker Compose ≥ 2.0
Python ≥ 3.11
Una clave de la API de OpenAI
Un conjunto de datos (documentación de Milvus en formato Markdown)

1. Desplegar Milvus

Download docker-compose.yml
wget https://github.com/milvus-io/milvus/releases/download/v2.6.8/milvus-standalone-docker-compose.yml -O docker-compose.yml
Start Milvus（verify port mapping：19530:19530）
docker-compose up -d
Verify that the services are running
docker ps | grep milvus
You should see three containers：milvus-standalone, milvus-etcd, milvus-minio

2. Implementación del núcleo

Integración de Milvus (ingest.py)

Nota: La implementación admite hasta ocho categorías de documentos. Si el número de categorías supera este límite, los colores se reutilizan de forma rotatoria.

from pymilvus import MilvusClient
from pymilvus.milvus_client.index import IndexParams
from openai import OpenAI
from langchain_text_splitters import RecursiveCharacterTextSplitter
import umap
from sklearn.neighbors import NearestNeighbors
import json
import numpy as np
import os
import glob
--- CONFIG ---
MILVUS_URI = "http://localhost:19530"
COLLECTION_NAME = "golem_memories"
JSON_OUTPUT_PATH = "./golem_cortex.json"
Data directory (users place .md files in this folder)
DATA_DIR = "./data"
OpenAI Embedding Config
OPENAI_API_KEY = os.getenv("OPENAI_API_KEY")
OPENAI_BASE_URL = "https://api.openai.com/v1"  #
OPENAI_EMBEDDING_MODEL = "text-embedding-3-small"
1536 dimensions
EMBEDDING_DIM = 1536
Color mapping: colors are assigned automatically and reused in a round-robin manner
COLORS = [
[0.29, 0.87, 0.50],
Green
[0.22, 0.74, 0.97],
Blue
[0.60, 0.20, 0.80],
Purple
[0.94, 0.94, 0.20],
Gold
[0.98, 0.55, 0.00],
Orange
[0.90, 0.30, 0.40],
Red
[0.40, 0.90, 0.90],
Cyan
[0.95, 0.50, 0.90],
Magenta
]
def get_embeddings(texts):
"""Batch embedding using OpenAI API"""
client = OpenAI(api_key=OPENAI_API_KEY, base_url=OPENAI_BASE_URL)
embeddings = []
batch_size = 100
OpenAI allows multiple texts per request
for i in range(0, len(texts), batch_size):
batch = texts[i:i + batch_size]
response = client.embeddings.create(
model=OPENAI_EMBEDDING_MODEL,
input=batch
)
embeddings.extend([item.embedding for item in response.data])
print(f"   ↳ Embedded {min(i + batch_size, len(texts))}/{len(texts)}...")
return np.array(embeddings)
def load_markdown_files(data_dir):
"""Load all markdown files from the data directory"""
md_files = glob.glob(os.path.join(data_dir, "**/*.md"), recursive=True)
if not md_files:
print(f"   ❌ ERROR: No .md files found in '{data_dir}'")
print(f"   👉 Create a '{data_dir}' folder and put your markdown files there.")
print(f"   👉 Example: {data_dir}/doc1.md, {data_dir}/docs/doc2.md")
return None
docs = []
print(f"\n📚 FOUND {len(md_files)} MARKDOWN FILES:")
for i, file_path in enumerate(md_files):
filename = os.path.basename(file_path)
Categories are derived from the file’s path relative to data_dir
rel_path = os.path.relpath(file_path, data_dir)
category = os.path.dirname(rel_path) if os.path.dirname(rel_path) else "default"
with open(file_path, 'r', encoding='utf-8') as f:
content = f.read()
docs.append({
"title": filename,
"text": content,
"cat": category,
"path": file_path
})
print(f"   {i+1}. [{category}] {filename}")
return docs
def ingest_dense():
print(f"🧠 PROJECT GOLEM - NEURAL MEMORY BUILDER")
print(f"=" * 50)
if not OPENAI_API_KEY:
print("   ❌ ERROR: OPENAI_API_KEY environment variable not set!")
print("   👉 Run: export OPENAI_API_KEY='your-key-here'")
return
print(f"   ↳ Using OpenAI Embedding: {OPENAI_EMBEDDING_MODEL}")
print(f"   ↳ Embedding Dimension: {EMBEDDING_DIM}")
print(f"   ↳ Data Directory: {DATA_DIR}")
1. Load local markdown files
docs = load_markdown_files(DATA_DIR)
if docs is None:
return
2. Split documents into chunks
print(f"\n📦 PROCESSING DOCUMENTS...")
splitter = RecursiveCharacterTextSplitter(chunk_size=800, chunk_overlap=50)
chunks = []
raw_texts = []
colors = []
chunk_titles = []
categories = []
for doc in docs:
doc_chunks = splitter.create_documents([doc['text']])
cat_index = hash(doc['cat']) % len(COLORS)
for i, chunk in enumerate(doc_chunks):
chunks.append({
"text": chunk.page_content,
"title": doc['title'],
"cat": doc['cat']
})
raw_texts.append(chunk.page_content)
colors.append(COLORS[cat_index])
chunk_titles.append(f"{doc['title']} (chunk {i+1})")
categories.append(doc['cat'])
print(f"   ↳ Created {len(chunks)} text chunks from {len(docs)} documents")
3. Generate embeddings
print(f"\n🔮 GENERATING EMBEDDINGS...")
vectors = get_embeddings(raw_texts)
4. 3D Projection (UMAP)
print("\n🎨 CALCULATING 3D MANIFOLD...")
reducer = umap.UMAP(n_components=3, n_neighbors=30, min_dist=0.1, metric='cosine')
embeddings_3d = reducer.fit_transform(vectors)
5. Wiring (KNN)
print("   ↳ Wiring Synapses (finding connections)...")
nbrs = NearestNeighbors(n_neighbors=8, metric='cosine').fit(vectors)
distances, indices = nbrs.kneighbors(vectors)
6. Prepare output data
cortex_data = []
milvus_data = []
for i in range(len(chunks)):
cortex_data.append({
"id": i,
"title": chunk_titles[i],
"cat": categories[i],
"pos": embeddings_3d[i].tolist(),
"col": colors[i],
"nbs": indices[i][1:].tolist()
})
milvus_data.append({
"id": i,
"text": chunks[i]['text'],
"title": chunk_titles[i],
"category": categories[i],
"vector": vectors[i].tolist()
})
with open(JSON_OUTPUT_PATH, 'w') as f:
json.dump(cortex_data, f)
7. Store vectors in Milvus
print("\n💾 STORING IN MILVUS...")
client = MilvusClient(uri=MILVUS_URI)
Drop existing collection if it exists
if client.has_collection(COLLECTION_NAME):
print(f"   ↳ Dropping existing collection '{COLLECTION_NAME}'...")
client.drop_collection(COLLECTION_NAME)
Create new collection
print(f"   ↳ Creating collection '{COLLECTION_NAME}' (dim={EMBEDDING_DIM})...")
client.create_collection(
collection_name=COLLECTION_NAME,
dimension=EMBEDDING_DIM
)
Insert data
print(f"   ↳ Inserting {len(milvus_data)} vectors...")
client.insert(
collection_name=COLLECTION_NAME,
data=milvus_data
)
Create index for faster search
print("   ↳ Creating index...")
index_params = IndexParams()
index_params.add_index(
field_name="vector",
index_type="AUTOINDEX",
metric_type="COSINE"
)
client.create_index(
collection_name=COLLECTION_NAME,
index_params=index_params
)
print(f"\n✅ CORTEX GENERATED SUCCESSFULLY!")
print(f"   📊 {len(chunks)} memory nodes stored in Milvus")
print(f"   📁 Cortex data saved to: {JSON_OUTPUT_PATH}")
print(f"   🚀 Run 'python GolemServer.py' to start the server")
if __name__ == "__main__":
ingest_dense()

Visualización del frontend (GolemServer.py)

from flask import Flask, request, jsonify, send_from_directory
from openai import OpenAI
from pymilvus import MilvusClient
import json
import os
import sys
--- CONFIG ---
Explicitly set the folder to where this script is located
BASE_DIR = os.path.dirname(os.path.abspath(__file__))
OpenAI Embedding Config
OPENAI_API_KEY = os.getenv("OPENAI_API_KEY")
OPENAI_BASE_URL = "https://api.openai.com/v1"
OPENAI_EMBEDDING_MODEL = "text-embedding-3-small"
Milvus Config
MILVUS_URI = "http://localhost:19530"
COLLECTION_NAME = "golem_memories"
These match the files generated by ingest.py
JSON_FILE = "golem_cortex.json"
UPDATED: Matches your new repo filename
HTML_FILE = "index.html"
app = Flask(__name__, static_folder=BASE_DIR)
print(f"\n🧠 PROJECT GOLEM SERVER")
print(f"   📂 Serving from: {BASE_DIR}")
--- DIAGNOSTICS ---
Check if files exist before starting
missing_files = []
if not os.path.exists(os.path.join(BASE_DIR, JSON_FILE)):
missing_files.append(JSON_FILE)
if not os.path.exists(os.path.join(BASE_DIR, HTML_FILE)):
missing_files.append(HTML_FILE)
if missing_files:
print(f"   ❌ CRITICAL ERROR: Missing files in this folder:")
for f in missing_files:
print(f"      - {f}")
print("   👉 Did you run 'python ingest.py' successfully?")
sys.exit(1)
else:
print(f"   ✅ Files Verified: Cortex Map found.")
Check API Key
if not OPENAI_API_KEY:
print(f"   ❌ CRITICAL ERROR: OPENAI_API_KEY environment variable not set!")
print("   👉 Run: export OPENAI_API_KEY='your-key-here'")
sys.exit(1)
print(f"   ↳ Using OpenAI Embedding: {OPENAI_EMBEDDING_MODEL}")
print("   ↳ Connecting to Milvus...")
milvus_client = MilvusClient(uri=MILVUS_URI)
Verify collection exists
if not milvus_client.has_collection(COLLECTION_NAME):
print(f"   ❌ CRITICAL ERROR: Collection '{COLLECTION_NAME}' not found in Milvus.")
print("   👉 Did you run 'python ingest.py' successfully?")
sys.exit(1)
Initialize OpenAI client
openai_client = OpenAI(api_key=OPENAI_API_KEY, base_url=OPENAI_BASE_URL)
--- ROUTES ---
@app.route('/')
def root():
Force serve the specific HTML file
return send_from_directory(BASE_DIR, HTML_FILE)
@app.route('/')
def serve_static(filename):
return send_from_directory(BASE_DIR, filename)
@app.route('/query', methods=['POST'])
def query_brain():
data = request.json
text = data.get('query', '')
if not text: return jsonify({"indices": []})
print(f"🔎 Query: {text}")
Get query embedding from OpenAI
response = openai_client.embeddings.create(
model=OPENAI_EMBEDDING_MODEL,
input=text
)
query_vec = response.data[0].embedding
Search in Milvus
results = milvus_client.search(
collection_name=COLLECTION_NAME,
data=[query_vec],
limit=50,
output_fields=["id"]
)
Extract indices and scores
indices = [r['id'] for r in results[0]]
scores = [r['distance'] for r in results[0]]
return jsonify({
"indices": indices,
"scores": scores
})
if __name__ == '__main__':
print("   ✅ SYSTEM ONLINE: http://localhost:8000")
app.run(port=8000)

Descargue el conjunto de datos y colóquelo en el directorio especificado

https://github.com/milvus-io/milvus-docs/tree/v2.6.x/site/en

3. Iniciar el proyecto

Conversión de las incrustaciones de texto al espacio 3D

python ingest.py

[imagen]

Iniciar el servicio de frontend

python GolemServer.py

4. Visualización e interacción

Una vez que el frontend recibe los resultados de la recuperación, el brillo de los nodos se escala en función de las puntuaciones de similitud del coseno, mientras que los colores originales de los nodos se conservan para mantener claros los grupos de categorías. Se trazan líneas semitransparentes desde el punto de consulta hasta cada nodo coincidente, y la cámara se desplaza y amplía suavemente para enfocar el clúster activado.

Ejemplo 1: Coincidencia en el dominio

Consulta: "¿Qué tipos de índice admite Milvus?"

Comportamiento de visualización:

En el espacio 3D, aproximadamente 15 nodos dentro del cluster rojo etiquetado INDEXES muestran un notable aumento de brillo (alrededor de 2-3×).
Los nodos coincidentes incluyen fragmentos de documentos como index_types.md, hnsw_index.md e ivf_index.md.
Se representan líneas semitransparentes desde el vector de consulta hasta cada nodo coincidente, y la cámara enfoca suavemente el clúster rojo.

Ejemplo 2: Rechazo de consultas fuera del dominio

Consulta: "¿Cuánto cuesta la comida de KFC?"

Comportamiento de la visualización:

Todos los nodos conservan sus colores originales, con ligeros cambios de tamaño (menos de 1,1×).
Los nodos coincidentes están dispersos en varios grupos con colores diferentes, sin mostrar una concentración semántica clara.
La cámara no desencadena una acción de enfoque, ya que no se alcanza el umbral de similitud (0,5).

Conclusión

Project_Golem emparejado con Milvus no sustituirá a su proceso de evaluación RAG existente, pero añade algo de lo que la mayoría de los procesos carecen por completo: la capacidad de ver lo que está sucediendo dentro del espacio vectorial.

Con esta configuración, se puede distinguir entre un fallo de recuperación causado por una mala incrustación, uno causado por una mala fragmentación y uno causado por un umbral demasiado ajustado. Este tipo de diagnóstico solía requerir conjeturas e iteraciones. Ahora se puede ver.

La integración actual soporta la depuración interactiva a escala de demostración (~10.000 documentos), con la base de datos vectorial de Milvus gestionando la recuperación a nivel de producción entre bastidores. El camino hacia la visualización a escala de millones está trazado, pero aún no se ha construido, por lo que es un buen momento para participar.

Echa un vistazo a Project_Golem en GitHub, pruébalo con tu propio conjunto de datos y comprueba el aspecto real de tu espacio vectorial.

Si tienes preguntas o quieres compartir lo que encuentres, únete a nuestro canal de Slack o reserva una sesión de Milvus Office Hours para recibir orientación práctica sobre tu configuración.