Las bases de datos vectoriales y los embeddings conllevan cuatro riesgos principales para un equipo de marketing: datos privados que se vuelven buscables por las personas equivocadas, recuperaciones que devuelven pasajes plausibles pero incorrectos, embeddings que quedan obsoletos cuando el contenido cambia y costos que aumentan silenciosamente a medida que crece el índice. La gobernanza significa decidir qué se puede incrustar, quién puede consultarlo, con qué frecuencia se actualiza y cómo se verifican las respuestas.
Un embedding es una lista de números que representa el significado de un fragmento de texto, una imagen o un registro de producto. Una base de datos vectorial como Pinecone, Weaviate, Qdrant, Milvus o la extensión pgvector para PostgreSQL almacena esas listas y encuentra las más cercanas a una consulta. Esa búsqueda de vecinos más cercanos es lo que subyace a la mayoría de los chatbots de generación aumentada por recuperación (RAG), la búsqueda semántica en sitios y los widgets de “productos similares”.
La tecnología es útil y bastante madura. El problema es que se siente como un cuadro de búsqueda, por lo que los equipos la tratan como tal. Se comporta de manera diferente y las reglas deben reflejar eso.
¿Qué hace que la búsqueda vectorial sea diferente de la búsqueda por palabras clave?
La búsqueda por palabras clave falla estrepitosamente. Si la palabra no está en el documento, no devuelve nada y alguien lo nota. La búsqueda vectorial casi nunca devuelve nada. Siempre encuentra la coincidencia más cercana, incluso cuando la coincidencia más cercana es débil, y clasifica esa coincidencia débil con la misma confianza que una fuerte.
Para un chatbot construido sobre RAG, esta es la raíz de la mayoría de las malas respuestas. El modelo de lenguaje recibe tres pasajes que están “más cerca” de la pregunta y escribe una respuesta fluida a partir de ellos. Si ninguno de los pasajes responde realmente a la pregunta, el modelo aún tiende a producir algo que suena correcto.
Una segunda diferencia: el significado es difuso. Un modelo de embedding puede colocar “cancelar mi suscripción” cerca de “pausar mi suscripción”, lo cual está bien para el descubrimiento pero es incorrecto para una respuesta de política. Los términos exactos como códigos de producto, precios y cláusulas legales son donde la búsqueda vectorial pura es más débil.
¿Qué riesgos debe planificar antes del lanzamiento?
Exposición de datos a través de la recuperación
El riesgo más grave es el acceso. Cuando un equipo incrusta una unidad compartida, el índice vectorial generalmente no hereda ninguno de los permisos de carpeta originales. La pregunta de un pasante al asistente interno puede recuperar un pasaje de una hoja de salarios o una presentación de precios no publicada, porque el índice solo sabe que el pasaje es semánticamente cercano.
Los embeddings en sí mismos tampoco son una forma segura de anonimización. La investigación sobre la inversión de embeddings ha demostrado que una buena parte del texto original puede reconstruirse a partir de vectores en algunos entornos. Trate los vectores almacenados con la misma sensibilidad que el texto fuente.
Contenido obsoleto y duplicado
Una página sobre la política de envío del año pasado permanece en el índice hasta que alguien elimina sus vectores. Si la nueva página de política también se incrusta, ambas se recuperan y el modelo puede mezclarlas. Los sitios de marketing cambian a menudo, con páginas de campaña, ofertas estacionales y servicios retirados, por lo que la obsolescencia es el estado predeterminado a menos que exista un trabajo de actualización.
Deriva silenciosa de la calidad
Cambiar el modelo de embedding, el tamaño del fragmento o la métrica de similitud cambia qué pasajes regresan. Mezclar vectores de dos modelos de embedding diferentes en un índice produce clasificaciones sin sentido, porque los dos modelos no comparten un espacio de coordenadas. Nada de esto arroja un error.
Crecimiento de costos
Los servicios vectoriales gestionados generalmente cobran por vectores almacenados, dimensiones, unidades de lectura y escritura, o una mezcla. Re-incrustar un sitio completo después de un cambio de modelo tiene su propio costo de API. Un piloto pequeño es barato; un índice de cada PDF que la empresa haya producido no lo es.
¿Cuáles son los límites técnicos que vale la pena conocer?
La mayoría de las bases de datos vectoriales utilizan índices de vecinos más cercanos aproximados (ANN) como HNSW o IVF. “Aproximado” es literal: por velocidad, el índice puede perder la verdadera coincidencia más cercana. Los parámetros de ajuste como ef_search en HNSW intercambian recuperación por latencia.
- El fragmentado (chunking) decide la calidad más que la marca de la base de datos. Una página de 2,000 palabras incrustada como un vector pierde detalle; dividida en piezas de 300 palabras con una pequeña superposición, generalmente se recupera mejor.
- El filtrado de metadatos (por idioma, fecha, línea de producto, nivel de acceso) es compatible con la mayoría de los motores, pero la búsqueda filtrada puede ser más lenta o menos precisa en algunos tipos de índice.
- El contenido multilingüe necesita un modelo de embedding multilingüe, de lo contrario, una pregunta en turco puede no encontrar la página en inglés que la responde.
- La búsqueda híbrida, que combina la puntuación de palabras clave BM25 con vectores, es la solución habitual para códigos, nombres y frases exactas. Weaviate, Qdrant, Elasticsearch y OpenSearch ofrecen alguna forma de ella.
Reglas de gobernanza a establecer primero
Escríbalas antes de incrustar el primer documento. Son cortas y previenen la mayoría de los incidentes anteriores.
- Lista de fuentes: nombre las carpetas, tipos de publicación de CMS o bases de datos que pueden ser incrustadas. Todo lo demás queda excluido por defecto.
- Reflejo de acceso: almacene una etiqueta de acceso con cada fragmento y filtre por ella en el momento de la consulta, de modo que un usuario solo recupere lo que ya podía abrir.
- Reglas de exclusión: sin datos personales, contratos, nóminas o credenciales en el índice. Escanee en busca de direcciones de correo electrónico y números de identificación antes de incrustar.
- Un modelo por índice: registre el nombre y la versión del modelo de embedding en los metadatos del índice. Un cambio de modelo significa un nuevo índice, no una actualización parcial.
- Programa de actualización: vuelva a incrustar el contenido cambiado al publicar y ejecute un trabajo semanal que elimine los vectores de las páginas no publicadas o eliminadas.
- Requisito de cita: cada respuesta del chatbot muestra los pasajes fuente que utilizó, para que los usuarios y revisores puedan verificarlos.
- Propietario: una persona nombrada aprueba nuevas fuentes y revisa los resultados de la evaluación cada mes.
¿Cómo prueba la calidad de la recuperación?
Construya un pequeño conjunto de evaluación antes del lanzamiento. De treinta a cincuenta preguntas reales, cada una emparejada con la página que debería responderla, es suficiente para un sitio de marketing. Ejecútelas después de cada cambio en la configuración de fragmentación, modelo o índice y registre con qué frecuencia aparece la página correcta en los tres primeros resultados.
Agregue un piso de similitud. Si la mejor coincidencia puntúa por debajo de un umbral que usted estableció a partir del conjunto de evaluación, el asistente debería decir que no sabe y ofrecer una ruta de contacto, en lugar de improvisar. Esta única regla elimina una gran parte de las respuestas incorrectas seguras.
Finalmente, lea los registros. Semanalmente, tome una muestra de veinte consultas reales y sus fragmentos recuperados. Los patrones aparecen rápidamente: una página que sigue apareciendo para preguntas no relacionadas, o un tema sin una buena fuente, lo cual es una brecha de contenido más que un problema de base de datos.
Cómo aplica Alien Road las bases de datos vectoriales y los embeddings
En un compromiso típico, el trabajo comienza con un inventario de contenido en lugar de una elección de base de datos. Enumeramos lo que el cliente publica, en qué idiomas y qué páginas pueden responder a las preguntas de los clientes. Las páginas de precios, legales y de campaña obtienen una etiqueta separada, porque cambian más y conllevan el mayor riesgo.
La configuración generalmente significa pgvector dentro de una instancia de PostgreSQL existente para sitios más pequeños, o un servicio gestionado cuando el índice es grande o multi-inquilino. Los fragmentos llevan metadatos de idioma, tipo de publicación, fecha de publicación y nivel de acceso, y un gancho de publicación vuelve a incrustar una página cada vez que cambia. La búsqueda híbrida se activa desde el primer día para nombres de productos y códigos de servicio.
La medición utiliza el conjunto de evaluación descrito anteriormente más dos señales en vivo: la parte de las sesiones de chatbot que terminan en una respuesta de “no sé” y la parte que hace clic en una fuente citada. Los informes mensuales muestran ambos, enumeran las preguntas sin una buena fuente y recomiendan el contenido a escribir a continuación. Esa última lista es a menudo el resultado más útil para el equipo de marketing.
Por dónde empezar esta semana
Elija un caso de uso estrecho, como responder preguntas de envío y devoluciones, e incruste solo las páginas que lo cubren. Escriba las siete reglas de gobernanza anteriores en un documento de una página y asigne un propietario. Luego, recopile treinta preguntas reales de clientes de tickets de soporte o registros de chat y utilícelas como su primer conjunto de prueba.
Una vez que ese pequeño índice responda de manera confiable, con fuentes mostradas y un camino claro de “no sé”, expanda una fuente a la vez. Crecer lentamente es lo que mantiene a una base de datos vectorial como un servicio de asistencia en lugar de una responsabilidad.
Siga leyendo: Optimización con IA · Optimización con IA