Editor de ChromaDB para Windows

A principios de 2026, mientras montaba un sistema de IA que traducía preguntas en lenguaje natural a consultas SQL sobre el ERP de un cliente, me encontré con que no había ninguna manera cómoda de revisar ni editar la base de conocimiento de ChromaDB sin abrir una terminal Python. Así que me hice el editor que me faltaba. Lo publiqué por si le sirve a alguien más.

01 — Qué es ChromaDB y para qué se usa

Cuando construyes un sistema de inteligencia artificial que tiene que "recordar" cosas — documentos, ejemplos, contexto, conocimiento de negocio — necesitas un sitio donde guardar esa información de forma que la IA pueda encontrarla de manera eficiente. No vale una base de datos SQL normal, porque la IA no busca por palabras exactas, sino por similitud semántica: busca frases que quieran decir lo mismo aunque usen palabras distintas.

Para eso existen las bases de datos vectoriales. ChromaDB es una de las más usadas: de código abierto, sencilla de instalar, con una API Python muy accesible, y con un rendimiento más que suficiente para proyectos de tamaño pequeño y mediano. La usan miles de proyectos de RAG (Retrieval-Augmented Generation), que es la técnica que permite que un modelo de lenguaje como GPT-4 o Claude consulte una base de conocimiento propia antes de responder.

En la práctica, ChromaDB guarda cada documento o ejemplo como un vector numérico (el "embedding") junto con el texto original y los metadatos que quieras añadir. Cuando el sistema necesita recordar algo relevante a una pregunta, convierte esa pregunta en un vector y busca los vectores más cercanos. Es una búsqueda por similitud, no por palabras clave.

En mi caso concreto, la base de conocimiento almacenaba pares de pregunta y consulta SQL: "¿Cuánto facturamos en 2025?" → SELECT SUM(importe_total) AS Facturacion_2025 FROM [TICKETS] WHERE YEAR(fecha_ticket) = 2025. El agente de IA, cuando recibía una pregunta nueva, buscaba los ejemplos más parecidos en ChromaDB y los usaba como contexto para generar la consulta correcta. A ese patrón se le llama RAG, y es una de las formas más fiables de conectar un modelo de lenguaje con datos reales de negocio sin tener que entrenarlo desde cero.

02 — El problema: una base de datos sin editor

ChromaDB es estupenda para lo que hace, pero tiene un punto débil práctico: no viene con ninguna interfaz para explorar ni editar los datos. Si quieres ver qué hay dentro, tienes que hacerlo por código Python. Si quieres corregir un par pregunta-respuesta que está mal, ídem. Si quieres borrar un registro duplicado, lo mismo.

Cuando la base de conocimiento tiene diez registros, no es problema. Cuando tiene varios cientos — y los vas añadiendo poco a poco mientras el sistema está en producción — se convierte en una fuente de frustración. Quieres ver la lista completa, buscar algo concreto, editar un SQL que está equivocado, borrar un ejemplo que ya no aplica... y para todo eso estás abriendo scripts de Python o la consola interactiva.

Internamente, ChromaDB persiste los datos en un archivo SQLite (chroma.sqlite3) que contiene todo el texto, los metadatos y un índice de texto completo FTS5. Los vectores van en carpetas aparte en formato binario. Lo primero es perfectamente legible y editable sin tocar Python ni el servidor de ChromaDB. Eso fue lo que me dio la idea.

03 — Qué hace el editor

La aplicación abre el archivo chroma.sqlite3 directamente y presenta los registros en una lista con columnas de pregunta, previsualización del SQL y fecha. En el panel derecho se carga el detalle completo del registro seleccionado: el texto de la pregunta y la consulta SQL asociada, ambos editables. Los cambios se guardan de vuelta al SQLite, incluida la actualización del índice FTS5.

Además de la edición básica, el editor incluye búsqueda por texto, paginación configurable para ver los últimos N registros o la colección completa, borrado individual o múltiple con confirmación, importación y exportación en formato JSONL, importación desde otra ChromaDB, y clonado completo de la base de datos (SQLite más las carpetas de índices vectoriales HNSW).

Hay también un análisis de tokens que estima cuántos tokens ocupa toda la base de conocimiento, con percentiles P90, P95, P99 y el máximo, y recomienda el valor de max_sequence_length a usar si se quiere hacer fine-tuning con frameworks como Axolotl. Es una estimación aproximada, pero para configurar un entrenamiento es suficiente.

Una aclaración importante que conviene entender: el editor trabaja con el texto y los metadatos, no con los vectores. Si importas registros nuevos desde fuera, esos registros son visibles y buscables por texto, pero no aparecerán en búsqueda semántica hasta que vuelvas a generar los embeddings con el pipeline de Python correspondiente. Es una limitación inherente a cómo funciona ChromaDB, no del editor.

04 — Sin Python, sin servidor, sin dependencias

La aplicación está hecha en VB.NET con Windows Forms sobre .NET 9. No necesita Python instalado, no necesita que el servidor de ChromaDB esté corriendo, no necesita nada más que ejecutar el .exe. El ejecutable publicado es autocontenido: incluye el runtime de .NET y la librería SQLite, y pesa alrededor de 50 MB.

La decisión de hacerlo en .NET nativo en lugar de una interfaz web o una extensión de VS Code fue deliberada. En el entorno de trabajo donde nació — un servidor Windows con IIS, sin Docker, sin entornos virtuales Python disponibles en todo momento — quería algo que se abriera con doble clic y funcionara. Sin instalar nada, sin configurar nada, sin depender de que el entorno Python del proyecto estuviera en orden.

Para la mayoría de proyectos que usan ChromaDB, el cuello de botella no es la búsqueda vectorial en sí — que ChromaDB resuelve muy bien — sino la gestión del conocimiento: curar los ejemplos, corregir los que están mal, añadir casos nuevos que el sistema no maneja bien. Para eso no hace falta un embedding model. Hace falta un editor de texto con un listado y un botón de guardar.

05 — GitHub, código fuente y descarga

El proyecto está publicado en GitHub con el código fuente completo, las instrucciones de compilación y un instalador generado con Inno Setup. La única dependencia externa es Microsoft.Data.Sqlite, que va incluida en el ejecutable final.

→ github.com/unmateria/.NET-ChromaDBEditor

No es un proyecto con grandes ambiciones de convertirse en producto. Es una herramienta que hice para un problema concreto, que funciona bien para ese problema, y que he dejado disponible por si alguien más está en una situación parecida. Si le resulta útil a alguien que está montando un sistema RAG con ChromaDB y no quiere abrir Python cada vez que necesita retocar la base de conocimiento, el objetivo estará cumplido.