E se você pudesse ver por que o RAG falha? Depuração do RAG em 3D com Project_Golem e Milvus

Quando a recuperação RAG corre mal, normalmente sabe-se que está avariada - os documentos relevantes não aparecem ou aparecem os irrelevantes. Mas descobrir porquê é uma história diferente. Tudo o que tem para trabalhar são as pontuações de semelhança e uma lista simples de resultados. Não há forma de ver como os documentos estão realmente posicionados no espaço vetorial, como os pedaços se relacionam entre si ou onde a sua consulta foi parar relativamente ao conteúdo que deveria ter correspondido. Na prática, isto significa que a depuração do RAG é sobretudo uma tentativa e erro: ajustar a estratégia de fragmentação, trocar o modelo de incorporação, ajustar o top-k e esperar que os resultados melhorem.

Project_Golem é uma ferramenta de código aberto que torna o espaço vetorial visível. Utiliza o UMAP para projetar embeddings de alta dimensão em 3D e o Three.js para os renderizar interactivamente no browser. Em vez de adivinhar porque é que a recuperação falhou, pode ver como os pedaços se agrupam semanticamente, onde é que a sua consulta chega e que documentos foram recuperados - tudo numa única interface visual.

Isto é fantástico. No entanto, o Project_Golem original foi concebido para pequenas demonstrações, não para sistemas do mundo real. Baseia-se em ficheiros planos, pesquisa de força bruta e reconstruções de conjuntos de dados completos - o que significa que falha rapidamente à medida que os seus dados crescem para além de alguns milhares de documentos.

Para colmatar essa lacuna, integrámos o Project_Golem com o Milvus (especificamente a versão 2.6.8) como a sua espinha dorsal vetorial. O Milvus é uma base de dados vetorial de alto desempenho de código aberto que lida com a ingestão em tempo real, indexação escalável e recuperação ao nível dos milissegundos, enquanto o Project_Golem se concentra naquilo que faz melhor: tornar visível o comportamento da recuperação vetorial. Juntos, eles transformam a visualização 3D de uma demonstração de brinquedo em uma ferramenta prática de depuração para sistemas RAG de produção.

Neste post, vamos apresentar o Project_Golem e mostrar como o integramos ao Milvus para tornar o comportamento de pesquisa vetorial observável, escalável e pronto para produção.

O que é o Project_Golem?

A depuração RAG é difícil por uma razão simples: os espaços vetoriais são altamente dimensionais e os humanos não conseguem vê-los.

O Project_Golem é uma ferramenta baseada no browser que lhe permite ver o espaço vetorial em que o seu sistema RAG opera. Pega nos embeddings de alta dimensão que conduzem à recuperação - normalmente 768 ou 1536 dimensões - e projecta-os numa cena 3D interactiva que pode explorar diretamente.

Eis como funciona nos bastidores:

• Redução da dimensionalidade com UMAP. O Project_Golem utiliza UMAP para comprimir vectores de alta dimensão para três dimensões, preservando as suas distâncias relativas. Os pedaços que são semanticamente semelhantes no espaço original ficam próximos uns dos outros na projeção 3D; os pedaços não relacionados acabam afastados.
• Renderização 3D com Three.js. Cada fragmento de documento aparece como um nó em uma cena 3D renderizada no navegador. Pode rodar, fazer zoom e explorar o espaço para ver como os seus documentos se agrupam - quais os tópicos que se agrupam mais, quais os que se sobrepõem e onde estão os limites.
• Realce em tempo de consulta. Quando executa uma consulta, a recuperação continua a ocorrer no espaço original de alta dimensão utilizando a semelhança de cosseno. Mas assim que os resultados chegam, os pedaços recuperados iluminam-se na vista 3D. Pode ver imediatamente onde a sua consulta foi parar em relação aos resultados - e, igualmente importante, em relação aos documentos que não foram recuperados.

É isto que torna o Project_Golem útil para a depuração. Em vez de olhar para uma lista classificada de resultados e adivinhar porque é que um documento relevante não foi encontrado, pode ver se está num grupo distante (um problema de incorporação), sobreposto com conteúdo irrelevante (um problema de fragmentação) ou mesmo fora do limite de recuperação (um problema de configuração). A vista 3D transforma pontuações de semelhança abstractas em relações espaciais sobre as quais se pode raciocinar.

Porque é que o Project_Golem não está pronto para a produção

O Project_Golem foi concebido como um protótipo de visualização, e funciona bem para isso. Mas a sua arquitetura faz suposições que se quebram rapidamente em escala - de formas que importam se quiser usá-lo para depuração RAG no mundo real.

Cada atualização requer uma recompilação completa

Esta é a limitação mais fundamental. No projeto original, a adição de novos documentos aciona uma reconstrução completa do pipeline: os embeddings são gerados novamente e gravados em arquivos .npy, o UMAP é executado novamente em todo o conjunto de dados e as coordenadas 3D são reexportadas como JSON.

Mesmo com 100.000 documentos, uma execução do UMAP de núcleo único leva de 5 a 10 minutos. Na escala de milhões de documentos, torna-se totalmente impraticável. Não é possível utilizar isto para qualquer conjunto de dados que mude continuamente - feeds de notícias, documentação, conversas de utilizadores - porque cada atualização significa esperar por um ciclo completo de reprocessamento.

A pesquisa à força bruta não tem escala

O lado da recuperação tem o seu próprio limite. A implementação original usa NumPy para pesquisa de força bruta de similaridade de cosseno - complexidade de tempo linear, sem indexação. Em um conjunto de dados de milhões de documentos, uma única consulta pode levar mais de um segundo. Isto é inutilizável para qualquer sistema interativo ou online.

A pressão da memória agrava o problema. Cada vetor float32 de 768 dimensões ocupa cerca de 3 KB, pelo que um conjunto de dados de um milhão de vectores requer mais de 3 GB de memória - tudo carregado numa matriz NumPy plana sem estrutura de índice para tornar a pesquisa eficiente.

Sem filtragem de metadados, sem aluguer múltiplo

Num sistema RAG real, a semelhança de vectores raramente é o único critério de recuperação. É quase sempre necessário filtrar por metadados, como o tipo de documento, carimbos de data/hora, permissões de utilizador ou limites ao nível da aplicação. Um sistema RAG de apoio ao cliente, por exemplo, precisa de limitar a recuperação aos documentos de um inquilino específico - e não procurar nos dados de todos.

O Project_Golem não suporta nada disto. Não existem índices ANN (como HNSW ou IVF), nem filtragem escalar, nem isolamento de inquilinos, nem pesquisa híbrida. Trata-se de uma camada de visualização sem um motor de recuperação de produção por baixo.

Como o Milvus alimenta a camada de recuperação do Project_Golem

A secção anterior identificou três lacunas: reconstruções completas em cada atualização, pesquisa de força bruta e nenhuma recuperação com reconhecimento de metadados. Todas as três resultam da mesma causa principal - o Project_Golem não tem uma camada de base de dados. A recuperação, o armazenamento e a visualização estão interligados num único pipeline, pelo que a alteração de qualquer parte obriga a uma reconstrução de tudo.

A solução não é otimizar esse pipeline. É dividi-lo em partes.

Ao integrar o Milvus 2.6.8 como a espinha dorsal do vetor, a recuperação torna-se uma camada dedicada, de nível de produção, que funciona independentemente da visualização. O Milvus trata do armazenamento vetorial, da indexação e da pesquisa. O Project_Golem concentra-se puramente na renderização - consumindo IDs de documentos do Milvus e destacando-os na vista 3D.

Esta separação produz dois fluxos limpos e independentes:

Fluxo de recuperação (online, ao nível dos milissegundos)

• A sua consulta é convertida num vetor utilizando os embeddings OpenAI.
• O vetor de consulta é enviado para uma coleção Milvus.
• O Milvus AUTOINDEX seleciona e optimiza o índice apropriado.
• Uma pesquisa de similaridade de cosseno em tempo real retorna os IDs de documentos relevantes.

Fluxo de visualização (offline, escala de demonstração)

• O UMAP gera coordenadas 3D durante a ingestão de dados (n_neighbors=30, min_dist=0.1).
• As coordenadas são armazenadas em golem_cortex.json.
• O frontend destaca os nós 3D correspondentes utilizando os IDs de documentos devolvidos pelo Milvus.

O ponto crítico: a recuperação já não espera pela visualização. É possível ingerir novos documentos e pesquisá-los imediatamente - a visualização em 3D é actualizada de acordo com o seu próprio calendário.

O que os nós de streaming mudam

Esta ingestão em tempo real é alimentada por uma nova capacidade no Milvus 2.6.8: Streaming Nodes. Nas versões anteriores, a ingestão em tempo real exigia uma fila de mensagens externa como Kafka ou Pulsar. Os Streaming Nodes transferem essa coordenação para o próprio Milvus - novos vectores são ingeridos continuamente, os índices são actualizados de forma incremental e os documentos recém-adicionados tornam-se imediatamente pesquisáveis, sem reconstrução completa e sem dependências externas.

Para o Project_Golem, é isto que torna a arquitetura prática. Pode continuar a adicionar documentos ao seu sistema RAG - novos artigos, documentos actualizados, conteúdo gerado pelo utilizador - e a recuperação mantém-se actualizada sem desencadear o dispendioso ciclo UMAP → JSON → recarregar.

Extensão da visualização para a escala de milhões (caminho futuro)

Com esta configuração apoiada pelo Milvus, o Project_Golem suporta atualmente demonstrações interactivas de cerca de 10.000 documentos. A recuperação é muito maior do que isso - Milvus lida com milhões - mas o pipeline de visualização ainda depende de execuções UMAP em lote. Para colmatar essa lacuna, a arquitetura pode ser alargada com um pipeline de visualização incremental:

• Accionadores de atualização: O sistema fica à escuta de eventos de inserção na coleção Milvus. Quando os documentos recentemente adicionados atingem um limite definido (por exemplo, 1000 itens), é desencadeada uma atualização incremental.

• Projeção incremental: Em vez de voltar a executar o UMAP em todo o conjunto de dados, os novos vectores são projectados no espaço 3D existente utilizando o método transform() do UMAP. Isto preserva a estrutura global enquanto reduz drasticamente o custo de computação.

• Sincronização de front-end: Os fragmentos de coordenadas actualizados são transmitidos para o frontend via WebSocket, permitindo que novos nós apareçam dinamicamente sem recarregar toda a cena.

Para além da escalabilidade, o Milvus 2.6.8 permite a pesquisa híbrida, combinando a semelhança vetorial com a pesquisa de texto completo e a filtragem escalar. Isto abre a porta a interações 3D mais ricas - tais como realce de palavras-chave, filtragem de categorias e cortes baseados no tempo - dando aos programadores formas mais poderosas de explorar, depurar e raciocinar sobre o comportamento RAG.

Como implantar e explorar o Project_Golem com o Milvus

O Project_Golem atualizado agora é de código aberto no GitHub. Usando a documentação oficial do Milvus como nosso conjunto de dados, percorremos todo o processo de visualização da recuperação de RAG em 3D. A configuração usa Docker e Python e é fácil de seguir, mesmo se você estiver começando do zero.

Pré-requisitos

• Docker ≥ 20.10
• Docker Compose ≥ 2.0
• Python ≥ 3.11
• Uma chave da API da OpenAI
• Um conjunto de dados (documentação do Milvus em formato Markdown)

1. Implementar o 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. Implementação principal

Integração do Milvus (ingest.py)

Nota: A implementação suporta até oito categorias de documentos. Se o número de categorias exceder este limite, as cores são reutilizadas de forma round-robin.

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()

Visualização do 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)

Descarregue o conjunto de dados e coloque-o no diretório especificado

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

3. Iniciar o projeto

Converter texto em espaço 3D

python ingest.py

[image]

Iniciar o serviço de front-end

python GolemServer.py

4. Visualização e interação

Depois de o frontend receber os resultados da recuperação, o brilho do nó é escalado com base nas pontuações de semelhança de cosseno, enquanto as cores originais do nó são preservadas para manter grupos de categorias claras. São desenhadas linhas semi-transparentes do ponto de consulta para cada nó correspondente, e a câmara faz uma panorâmica e um zoom suaves para focar o cluster ativado.

Exemplo 1: Correspondência no domínio

Consulta: "Quais os tipos de índice suportados pelo Milvus?"

Comportamento de visualização:

• No espaço 3D, aproximadamente 15 nós dentro do cluster vermelho rotulado INDEXES mostram um aumento notável no brilho (cerca de 2-3×).

• Os nós correspondentes incluem pedaços de documentos como index_types.md, hnsw_index.md e ivf_index.md.

• São apresentadas linhas semi-transparentes do vetor de consulta para cada nó correspondente, e a câmara foca suavemente o cluster vermelho.

Exemplo 2: Rejeição de consulta fora do domínio

Consulta: "Quanto custa a refeição económica do KFC?"

Comportamento de visualização:

• Todos os nós mantêm as suas cores originais, com apenas ligeiras alterações de tamanho (menos de 1,1×).

• Os nós correspondentes estão espalhados por vários grupos com cores diferentes, não mostrando uma concentração semântica clara.

• A câmara não desencadeia uma ação de focagem, uma vez que o limiar de semelhança (0,5) não é atingido.

Conclusão

O Project_Golem emparelhado com o Milvus não substituirá o seu pipeline de avaliação RAG existente - mas acrescenta algo que falta totalmente à maioria dos pipelines: a capacidade de ver o que está a acontecer dentro do espaço vetorial.

Com esta configuração, é possível distinguir entre uma falha de recuperação causada por uma má incorporação, uma falha causada por uma má fragmentação e uma falha causada por um limiar ligeiramente demasiado apertado. Esse tipo de diagnóstico costumava exigir adivinhação e iteração. Agora é possível vê-lo.

A integração atual suporta a depuração interactiva à escala de demonstração (~10.000 documentos), com a base de dados de vectores Milvus a tratar da recuperação de nível de produção nos bastidores. O caminho para a visualização à escala de um milhão está traçado, mas ainda não foi construído - o que faz com que esta seja uma boa altura para participar.

Veja o Project_Golem no GitHub, experimente-o com o seu próprio conjunto de dados e veja como é o seu espaço vetorial.

Se tiver dúvidas ou quiser partilhar o que encontrar, junte-se ao nosso canal Slack ou marque uma sessão Milvus Office Hours para obter orientação prática sobre a sua configuração.