Servicio de búsqueda semántica con una base de datos vectorial de Pinecone detrás de un servidor MCP.

Un modelo de lenguaje solo puede responder basándose en lo que vio durante su entrenamiento. Los estándares de ingeniería, los manuales de políticas, las especificaciones de productos y las wikis internas le resultan invisibles a menos que ese material se proporcione al hacer la pregunta. El proceso descrito aquí se encarga de eso para colecciones de PDF: los documentos se integran una vez en Pinecone, y cualquier agente de IA puede consultarlos a través de un servidor MCP creado con el SDK FastMCP.

Por qué la búsqueda por palabras clave no es suficiente

La búsqueda simple por palabras clave parece la solución obvia, pero rara vez las personas formulan una pregunta con las palabras exactas que utiliza la documentación, por lo que los pasajes relevantes se pasan por alto. Los diccionarios de sinónimos y la expansión de consultas ayudan, pero ambos dependen de relaciones entre palabras definidas manualmente por alguien. Ninguno de ellos comprende el significado de las palabras.

La búsqueda semántica sigue un camino diferente. Tanto los documentos como las consultas se convierten en embeddings vectoriales que codifican el significado, y la relevancia se determina comparando esos vectores mediante la similitud de coseno, una medida de cuán cerca apuntan dos vectores en la misma dirección en el espacio de embeddings. Una puntuación más alta indica un vínculo semántico más fuerte, por lo que las secciones relacionadas aparecen incluso si el vocabulario difiere por completo. Una pregunta como “¿Cómo convierten las plantas la luz solar en energía?” puede hacer que aparezcan textos sobre cloroplastos y fotosíntesis, aunque ninguno de esos términos aparezca en ellos.

Dos componentes: la base de datos vectorial y el servidor MCP

El sistema se divide en dos partes que pueden cambiar de forma independiente: un pipeline de ingestión y un servidor MCP. La ingestión se ejecuta una vez por documento. Después de eso, cualquier agente conectado puede consultar una y otra vez los mismos conocimientos indexados a través del servidor.

El pipeline de ingestión convierte los PDFs en bruto en vectores buscables. Extrae el texto, lo divide en fragmentos superpuestos, crea embeddings con Pinecone Inference y escribe los vectores en un índice de Pinecone. Incrustar una gran colección requiere recursos de cómputo reales, por lo que un registro simple evita tareas repetidas. Para cada archivo indexado, almacena la hora del último embedding. En la siguiente ejecución, el pipeline compara la hora de modificación actual de cada archivo con la almacenada. Un documento modificado recibe embeddings nuevos, mientras que uno sin cambios mantiene sus vectores existentes. La base de datos se mantiene al día con las ediciones de los documentos y no se realizan llamadas redundantes de embedding.

El servidor MCP, desarrollado sobre FastMCP, recibe una pregunta en lenguaje natural de un agente, la incrusta, realiza una búsqueda de similitud contra Pinecone y devuelve los fragmentos con las puntuaciones más altas. Dado que la interfaz es MCP, varias aplicaciones de IA pueden compartir un mismo servicio de recuperación sin conocer nada sobre la base de datos vectorial ni el modelo de incrustación que está detrás de ella.

Separar estas dos partes fue una decisión deliberada. Cambiar los modelos de incrustación, ajustar el método de fragmentación o reconstruir el índice vectorial puede realizarse sin tocar la interfaz MCP ni ningún agente que dependa de ella.

Creación del pipeline de incrustación y fragmentación

Los PDF están diseñados para ser leídos por ojos humanos, no para su recuperación por máquinas, por lo que primero deben convertirse en una representación que capture su significado. El proceso comienza extrayendo el texto de cada archivo con la biblioteca pypdf de Python, leyendo página por página y uniendo los resultados en una sola cadena para facilitar su manejo posterior. Acepta archivos individuales así como directorios completos, de modo que los nuevos conjuntos de documentos pueden indexarse sin necesidad de realizar cambios en la parte de recuperación.

Elegir cómo dividir en partes

Una vez extraído el texto, el documento se divide en partes más pequeñas llamadas fragmentos, y esa decisión resultó ser una de las más importantes en todo el proceso. Los modelos de embedding tienen ventanas de contexto fijas, lo que impide representar todo un documento como un único vector. Incluso cuando un documento cabe, una sola representación de todo el archivo ofrece una visión general y poco precisa, ya que varios temas no relacionados se mezclan entre sí y disminuye la exactitud en la recuperación de información.

Cada documento se divide en fragmentos de tamaño fijo que se superponen, lo que permite que cada representación vectorial corresponda a un rango de texto más pequeño y específico. Elegir el tamaño adecuado implica encontrar un equilibrio entre el contexto y la precisión. Los fragmentos pequeños suelen proporcionar resultados más exactos, ya que cada representación vectorial captura una idea más limitada, aunque generan más vectores y aumentan el tiempo de indexación y el almacenamiento necesario. Los fragmentos grandes conservan más contexto circundante y reducen la cantidad de vectores, pero cada representación vectorial abarca un rango de información más amplio, lo que puede disminuir la precisión. La división en fragmentos semánticos o conscientes de la oración constituye una opción más avanzada, sin embargo, la división simple en fragmentos de tamaño fijo resultó ser una base sencilla y eficaz para la recuperación de información de uso general.

chunks = [
    text[i:i+500]
    for i in range(0, len(text), 450)
]

/*
Fixed-size overlapping chunk generation used during document ingestion.
A chunk length of 500 characters and a stride of 450 characters preserve
contextual continuity while maintaining semantic specificity.
*/

Embebidos con Pinecone

A continuación, los fragmentos se convierten en embebidos. Un embebido es una representación numérica densa de texto que codifica su significado. En lugar de buscar palabras clave, la búsqueda semántica compara vectores, de modo que los pasajes relacionados coinciden a pesar de tener un vocabulario diferente. Los vectores de “gato” y “perro” se encuentran cerca uno del otro en el espacio de embebidos, mientras que “gato” y “avión” están muy separados, lo que permite calcular la similitud de forma matemática y no mediante una coincidencia exacta de palabras.

El modelo de embebidos utilizado aquí es el multilingual-e5-large alojado por Pinecone, al que se accede a través de la API de inferencia de Pinecone. Al tratarse de un servicio alojado, no hay un modelo de aprendizaje automático separado que sea necesario desplegar o mantener, por lo que el código de procesamiento puede centrarse en el manejo de documentos y la arquitectura se mantiene más simple.

Se eligió este modelo porque está optimizado para la recuperación semántica y abarca más de cien idiomas. La familia E5 también trata las consultas y los fragmentos de documentos como tipos de entrada diferentes, lo cual es adecuado para la recuperación de información. En el momento de indexar, los fragmentos se incluyen como pasajes, ya que son el contenido que se puede buscar. En el momento de realizar la consulta, la pregunta del usuario se incluye como tal. Ambos terminan en el mismo espacio semántico, lo que aumenta las posibilidades de encontrar el material adecuado incluso cuando la redacción difiere mucho.

En cuanto al rendimiento, los fragmentos se envían a la API en lotes de 96, que es el tamaño máximo que Pinecone Inference permite actualmente para el modelo multilingual-e5-large. Enviar muchos fragmentos por solicitud reduce la cantidad de llamadas a la API, aprovecha mejor los recursos y acorta el tiempo de indexación en comparación con enviar los fragmentos uno por uno. Los embeddings resultantes y sus metadatos se almacenan luego en la base de datos vectorial de Pinecone, listos para su recuperación.

embeddings = pc.inference.embed(
    model="multilingual-e5-large",
    inputs=batch,
    parameters={"input_type": "passage"}
)

El servidor MCP para búsquedas semánticas

Una vez indexados los documentos, los agentes necesitan una forma de acceder a ellos. En lugar de exponer la base de datos vectorial directamente a las aplicaciones, un servidor de Model Context Protocol desarrollado con FastMCP se encarga de gestionarla. MCP proporciona a las aplicaciones de IA una forma estándar de llamar a las herramientas, de modo que cualquier cliente compatible puede utilizar la recuperación de información sin necesidad de conocer la base de datos o el modelo de incrustación subyacente. Esta capa adicional permite reutilizar el código de recuperación, mantenerlo fácil de mantener y mantenerlo desacoplado de las aplicaciones que lo utilizan.

La recuperación de información es la función principal del servidor. Cuando un agente envía una pregunta, el servidor la incrusta con el mismo modelo multilingual-e5-large utilizado en el momento del indexado, realiza una búsqueda de similitud en el índice de Pinecone y devuelve los fragmentos mejor clasificados. El uso de un mismo modelo en ambos procesos mantiene los fragmentos y las consultas en el mismo espacio semántico, lo que hace que su comparación tenga sentido.

Para mejorar la calidad de los resultados, la herramienta de búsqueda solo muestra coincidencias con una similitud coseno superior a 0.82. En los experimentos, las puntuaciones por encima de este valor generalmente indicaban una fuerte correspondencia semántica entre la consulta y el fragmento de texto, mientras que las puntuaciones más bajas solían reflejar una relación, cuando mucho, superficial. Al descartar las coincidencias menos relevantes, se proporciona a los modelos de lenguaje posteriores un contexto más pertinente. Una pregunta como “¿Cómo presento un informe de gastos?” puede llegar a la página de políticas correcta incluso si el documento la expresa de manera diferente. Además de la búsqueda, el servidor ofrece herramientas para mantener la base de datos vectorial: insertar vectores, eliminarlos y listar los índices disponibles.

Dado que el sistema está diseñado para su implementación en empresas, la seguridad forma parte de su estructura. Las credenciales provienen de Azure Key Vault, y cada solicitud requiere una clave API válida antes de que se ejecute cualquier operación de recuperación. Los detalles sensibles de la infraestructura permanecen alejados de las aplicaciones del cliente, y el acceso a los documentos indexados está protegido.

results = index.query(
    vector=query_embedding,
    top_k=5,
    include_metadata=True
)

Qué muestra el proyecto sobre RAG para documentos internos

Un sistema de búsqueda semántica eficaz depende tanto de las decisiones de ingeniería como de los modelos de lenguaje subyacentes. La estrategia de fragmentación, el modelo de incrustación, el enfoque de agrupamiento por lotes y la arquitectura de recuperación influyen directamente en la calidad, escalabilidad y mantenibilidad. Al colocar las operaciones de ingestión y recuperación detrás de un servidor MCP se obtiene un sistema modular que es reutilizable, fácil de mantener y sencillo de ampliar a medida que cambian las necesidades.

La versión actual constituye una base sólida con amplio margen para evolucionar. El segmentado semántico, los modelos de reclasificación, la búsqueda híbrida y metadatos más detallados podrían mejorar aún más la recuperación de información manteniendo intacta la estructura modular. A medida que la generación reforzada por recuperación de información se vuelve algo habitual en la IA empresarial, la recuperación semántica fiable se está convirtiendo en un componente básico de los sistemas de producción, y combinar Pinecone Inference con una capa de recuperación MCP es una forma práctica y escalable de crear búsquedas semánticas reutilizables.