Qué es una base de datos vectorial y para qué sirve en una empresa

El dolor real: la empresa tiene la información y no la encuentra

En casi toda empresa con años de operación pasa lo mismo. El conocimiento existe, está guardado, alguien lo escribió bien en su momento, y aun así nadie lo encuentra cuando lo necesita. Un asesor arma una propuesta desde cero sin saber que hay tres casi idénticas en una carpeta compartida. Soporte escala un caso que ya se resolvió el año pasado. Legal revisa una cláusula ya negociada en los mismos términos con otro cliente. No es gente floja: es un problema de recuperación.

Ese costo no aparece en ningún reporte: se reparte en trabajo rehecho, respuestas tardías al cliente y conocimiento que se va con quien renuncia. Cuando llega el proyecto de IA, el dolor se hace evidente. El modelo razona bien, pero no conoce tu empresa. Ahí aparece la base de datos vectorial en la conversación, y ahí también empieza el error más caro de este tema: comprar infraestructura antes de saber qué pregunta del negocio se quiere responder.

Qué es de verdad, explicado sin jerga de ingeniería

En vez de conservar el texto para buscarlo por coincidencia de palabras, convierte cada fragmento en una lista larga de números que representa su significado. Esa lista se llama vector o embedding. Dos textos que hablan de lo mismo, aunque usen palabras completamente distintas, terminan con listas parecidas. Buscar deja de ser «encontrar esta palabra» y pasa a ser «encontrar lo más cercano a esto en significado».

El ejemplo que uso en reuniones de dirección: el cliente escribe «me llegó el producto roto» y tu manual llama a ese procedimiento «gestión de mercadería con daño en tránsito». Un buscador tradicional devuelve cero, porque no comparten una sola palabra clave. Una base vectorial lo devuelve primero. Eso es todo: no es inteligencia, es geometría aplicada a texto. Y nunca se usa sola: no estás comprando la solución, estás comprando el estante donde se guarda el material que después consulta el modelo.

Qué trabajo real implica ponerla a funcionar

Para dirección lo importante no es el algoritmo, sino el trabajo que hay detrás. No se llena sola ni se mantiene sola, y ahí se va el presupuesto que nadie presupuestó:

• Decidir qué entra: contratos, manuales, tickets resueltos, propuestas. Qué se indexa y qué no es una decisión de negocio, no técnica.
• Partir los documentos: un contrato de cuarenta páginas no entra como bloque único, y cómo se corta afecta directamente la calidad de las respuestas.
• Convertirlos en vectores y etiquetarlos: fecha, área, versión y quién puede verlo. Sin eso, una consulta devuelve lo que esa persona no debería ver.
• Consultar en tiempo real: la pregunta también se convierte en vector, se recuperan los fragmentos más cercanos y esos alimentan la respuesta, citando la fuente.
• Mantener: cuando cambia una política hay que reindexar; cuando se borra un documento hay que borrarlo también acá.

Los primeros pasos son un proyecto. El último es una operación permanente, y la mayoría presupuesta solo el proyecto. Por eso tantos buscadores internos arrancan brillantes y a los ocho meses están abandonados: no falló la tecnología, falló que nadie quedó a cargo de mantener el contenido vivo.

En qué se diferencia de la base de datos que la empresa ya tiene

Es la pregunta que siempre hace el gerente de sistemas y es la correcta. Tu empresa ya tiene bases de datos: la del ERP, la del CRM, la de facturación. Son relacionales y son extraordinariamente buenas en lo suyo, responder preguntas exactas sobre datos estructurados: qué facturas están vencidas, cuánto cerró cada vendedor en junio. Ahí la respuesta tiene que ser exacta al cien por ciento, y una base vectorial no compite con eso.

• Tipo de pregunta: la relacional responde «dame exactamente esto»; la vectorial responde «dame lo más parecido a esto».
• Resultado: la relacional devuelve el dato o nada; la vectorial devuelve candidatos ordenados por cercanía y siempre devuelve algo, aunque no sea bueno. Obliga a revisar la calidad, no a asumirla.
• Riesgo principal: en la relacional, un dato mal cargado; en la vectorial, un documento vencido que sigue indexado y que el modelo cita como si fuera vigente.

Y hay un matiz que casi nadie menciona en la venta: varias bases de datos relacionales de uso común ya soportan búsqueda vectorial como extensión. En muchos casos no hace falta comprar un motor nuevo ni sumar un proveedor al stack, basta con activarla sobre la infraestructura que ya administras. Preguntarlo antes de firmar un contrato anual ahorra bastante dinero.

Qué no es y qué no te va a resolver

Acá suelo bajar expectativas en la primera reunión, porque la brecha entre lo que se promete y lo que hace es grande. Una base de datos vectorial no piensa, no entiende tu negocio y no ordena tu desorden. Es un buscador muy bueno para texto: nada más y nada menos.

• No es inteligencia: recupera fragmentos parecidos. El razonamiento lo pone el modelo que va después y el criterio de negocio lo pones tú.
• No arregla documentación mala: si tus manuales están desactualizados o se contradicen, va a encontrar rápido el contenido malo. Amplifica el desorden, no lo corrige.
• No garantiza respuestas correctas: si recupera la versión vieja de una política, el modelo responderá con seguridad total sobre información equivocada.
• No resuelve permisos por sí sola: si el control de acceso no se diseñó desde el inicio, alguien terminará consultando documentos de otra área.

En varios proyectos donde la empresa pidió una base vectorial, el problema de fondo era que nadie había ordenado la información: cuatro carpetas con versiones distintas del mismo manual y nadie a cargo de decidir cuál era la buena. Ese trabajo hay que hacerlo igual, y con base vectorial se nota en la primera demo delante del directorio.

Cuándo hace falta de verdad y cuándo es sobreingeniería

El criterio no es el tamaño de la empresa, es el volumen y la volatilidad del contenido que hay que consultar. Un modelo actual lee bastante texto en una sola consulta: si todo tu material relevante cabe ahí, no necesitas infraestructura de búsqueda.

Cuándo sí tiene sentido

• El volumen de documentos es mayor de lo que se le puede pasar al modelo en cada consulta, y sigue creciendo mes a mes.
• El contenido cambia seguido: políticas que se actualizan, catálogos que se mueven, casos nuevos cada semana.
• Hay muchas consultas al día sobre el mismo cuerpo de conocimiento, de gente distinta y con formas de preguntar distintas.
• Ya tienes un caso de uso funcionando con pocos datos y el cuello de botella para escalarlo es la recuperación.

Cuándo es sobreingeniería

• El corpus completo son unas decenas de documentos estables. Un archivo bien estructurado hace el mismo trabajo sin sumar proveedor.
• La pregunta real era de dato exacto y hacía falta conectar el sistema al ERP, no montar un buscador semántico.
• Todavía no hay ningún caso de uso validado. Comprar el motor primero es comprar la respuesta antes de tener la pregunta.
• Nadie en el equipo puede operar la pieza y no hay presupuesto para que alguien externo la mantenga.

Los errores que se repiten en empresas reales

Casi todos los proyectos que terminan mal en este tema fallan por las mismas razones, y ninguna es técnica. Son de secuencia y de responsabilidad.

• Comprar la infraestructura antes de tener el caso de uso. Seis meses después hay un servicio facturando, documentos indexados y ninguna pregunta de negocio conectada a ellos. El orden correcto es al revés: qué pregunta cuesta dinero sin responder, quién la hace y cuántas veces al día.
• Indexar todo lo que existe. Volcar la carpeta compartida completa, con versiones viejas y duplicados: la búsqueda empeora porque el ruido compite con el contenido bueno. Y si conviven la política de 2023 y la de 2026, el sistema cita la que quede más cerca en significado, no la vigente.
• Dejar los permisos para el final. El control de acceso agregado después se agrega mal, y el proyecto se cae en la revisión de seguridad por bueno que sea el buscador.
• Medir el avance en documentos indexados. Nadie mejora su operación porque haya cuarenta mil fragmentos cargados.
• No poder rastrear de dónde salió una respuesta. Sin cita de la fuente nadie verifica nada, y en cuanto una respuesta salga mal la confianza se cae y no vuelve.

Cómo saber si de verdad funcionó

No se sabe con una demo impresionante ni con el conteo de documentos cargados. Se sabe si la operación mejoró en algo medible que alguien del negocio pueda defender delante del directorio. Estas son las señales que reviso, y todas exigen medir antes de implementar:

• Tiempo hasta encontrar la respuesta: cuánto le toma a una persona ubicar el antecedente que necesita, cronometrado sobre casos reales, antes y después.
• Consultas resueltas sin escalar a un experto: si la gente sigue preguntándole al de siempre, el sistema no se ganó la confianza.
• Precisión verificada por el dueño del contenido: tomar cincuenta preguntas reales y revisar si el documento correcto apareció entre los primeros resultados.
• Respuestas basadas en documentos vencidos: si sube, el proceso de actualización se rompió.
• Uso sostenido pasado el tercer mes: el pico de la primera semana no dice nada.
• Costo total mensual real: motor, embeddings, reindexaciones y horas de quien mantiene el contenido, contra el ahorro declarado.

Si a los tres meses ninguna de estas señales se movió, el diagnóstico casi nunca es que elegiste el motor equivocado. Es que el caso de uso no dolía lo suficiente, o que la información que indexaste no era la que la gente necesitaba. Cambiar de proveedor no arregla ninguna de las dos.