Buscador interno de documentos: por qué acierta o se inventa la respuesta

La búsqueda documental con IA es, de todos los proyectos que nos piden, el que mejor demo tiene y peor final si nadie mira debajo. La escena se repite: alguien pregunta «¿qué plazo de garantía damos a los clientes del contrato marco?», el asistente responde en dos segundos con un párrafo impecable y la sala aplaude. Tres semanas después, el mismo asistente responde con la misma seguridad usando la versión de 2021 de ese contrato, que sigue en una carpeta compartida porque nadie la borró nunca.

Esta guía explica qué es de verdad un buscador interno sobre documentos propios, qué piezas lleva dentro, cómo se comprueba que la respuesta es buena —con números, no con sensaciones— y por qué el 80 % de los fallos no están en el modelo sino en el repositorio. Si estás valorando montar uno, lo que decidas sobre el segundo punto pesará más que la elección de tecnología.

¿Qué es un buscador interno de documentos con IA?

Es un sistema que responde preguntas en lenguaje natural apoyándose solo en tus documentos, y que cita de dónde ha sacado cada afirmación. No es un modelo que «sabe» de tu empresa: es un buscador que recupera fragmentos relevantes y un modelo que redacta la respuesta a partir de esos fragmentos. El nombre técnico habitual es RAG (recuperación aumentada por generación), pero lo importante es la consecuencia práctica: si el fragmento correcto no se recupera, no hay modelo que salve la respuesta.

La diferencia con lo que ya tienes:

• Buscador clásico por palabras. Encuentra documentos que contienen las palabras que escribes. Si el contrato dice «periodo de subsanación» y tú buscas «plazo de garantía», no aparece.
• Buscador semántico. Encuentra documentos que hablan de lo mismo aunque usen otras palabras. Devuelve documentos, no respuestas.
• Buscador con IA generativa. Recupera fragmentos y redacta una respuesta con enlaces a la fuente. Ahorra el paso de abrir seis PDF y leerlos en diagonal.

Los tres son útiles y el tercero no sustituye a los dos primeros: los usa. Un sistema bien montado combina búsqueda por palabra exacta (imprescindible para referencias, códigos de artículo o números de expediente) con búsqueda semántica, y solo después genera texto.

La pregunta correcta no es «¿qué modelo uso?», sino «¿qué porcentaje de las veces el sistema pone delante del modelo el párrafo que contiene la respuesta?».

¿Qué problemas resuelve de verdad y cuáles no?

Casos donde aporta valor medible desde el primer mes:

• Soporte interno sobre normativa propia. Convenios, políticas de viaje, procedimientos de calidad, manuales de producto. Preguntas repetitivas, fuente escrita, respuesta verificable.
• Pliegos y licitaciones. Buscar en concursos anteriores cómo se respondió a un requisito concreto, con qué precio y con qué solvencia técnica.
• Departamento técnico o de posventa. Manuales, despieces, avisos de seguridad y notas de servicio repartidos en miles de PDF de distintos fabricantes.
• Contratos y cláusulas. Localizar todos los contratos con una cláusula de penalización o con revisión de precios indexada, y comparar redacciones.
• Incorporación de personal nuevo. Las 200 preguntas que hace alguien en sus tres primeros meses y que hoy consume el tiempo de un veterano.

Y los casos donde hoy decepciona, dicho sin rodeos:

• Preguntas agregadas. «¿Cuántos contratos vencen este trimestre?» no es una pregunta documental, es una consulta a una base de datos. Si la información está en tablas, el sitio es un cuadro de mando, no un buscador.
• Documentos contradictorios sin jerarquía. Si existen tres políticas de gastos vigentes y nadie sabe cuál manda, el sistema tampoco lo sabrá; te dará una de las tres.
• Escaneos malos y fotocopias de fax. Si el texto no se puede extraer con garantías, no hay nada que indexar. Ahí el trabajo previo es de extracción de datos de documentos.
• Decisiones que exigen responsabilidad jurídica. El sistema acelera la búsqueda de la cláusula; la interpretación sigue siendo de una persona con nombre y apellidos.

¿Cómo funciona por dentro y dónde se pierde la calidad?

Conviene conocer las seis etapas porque cada una tiene su propio modo de fallar, y el usuario final solo ve el resultado combinado.

| Etapa | Qué hace | Fallo típico | |---|---|---| | Ingesta | Recoge ficheros de las carpetas, el gestor documental o el correo | Se indexan borradores, copias y versiones antiguas | | Extracción | Convierte PDF, Word o escaneos en texto plano | Tablas que se deshacen, columnas que se mezclan, OCR sin revisar | | Troceado | Parte el documento en fragmentos indexables | Cortes a mitad de cláusula que dejan la condición sin su excepción | | Indexado | Crea el índice semántico y el de palabra exacta | Solo semántico: falla en códigos, referencias y nombres propios | | Recuperación | Selecciona los fragmentos candidatos para la pregunta | Se recuperan cinco fragmentos parecidos del mismo documento irrelevante | | Generación | Redacta la respuesta citando fuentes | Rellena huecos con lenguaje plausible cuando no ha recuperado lo necesario |

Dos observaciones de obra, no de manual. La primera: el troceado es la decisión más infravalorada del proyecto. Trocear cada 500 caracteres de forma ciega funciona en una wiki y destroza un contrato, donde el sentido de un apartado depende del artículo que lo precede. Respetar la estructura del documento —título, artículo, apartado— y arrastrar ese contexto en cada fragmento sube el acierto más que cambiar de modelo.

La segunda: los metadatos valen tanto como el texto. Fecha de vigencia, versión, país, sociedad, departamento y estado (vigente / derogado) permiten filtrar antes de buscar. Sin ellos, el sistema compite consigo mismo entre cinco versiones del mismo documento y gana la que mejor coincide literalmente, que casi nunca es la vigente.

¿Cómo se evalúa que la respuesta es buena?

Aquí es donde se separan los proyectos que llegan a producción de los que se quedan en demo. Evaluar no es preguntarle tres cosas y decir «funciona bastante bien». Es montar un conjunto de preguntas de referencia con respuesta conocida y medir cada vez que se toca algo.

Cómo se construye, con esfuerzo realista:

1. Reúne entre 50 y 150 preguntas reales. Salen de los tickets de soporte interno, del correo del responsable de calidad y de lo que pregunta la gente nueva. No las inventes en una sala. 2. Para cada una, anota la respuesta correcta y —esto es lo importante— el documento y el apartado exactos donde está. 3. Incluye a propósito 10-15 preguntas trampa: cosas que no están en ningún documento, preguntas ambiguas y preguntas cuya respuesta cambió el año pasado. 4. Ejecuta el conjunto entero en cada cambio de configuración y guarda los resultados con fecha.

Las métricas que usamos, en este orden:

| Métrica | Qué mide | Umbral orientativo | |---|---|---| | Acierto de recuperación | % de preguntas cuyo fragmento correcto está entre los recuperados | > 90 % antes de mirar nada más | | Fidelidad a la fuente | % de afirmaciones de la respuesta respaldadas por el fragmento citado | > 95 % | | Respuesta correcta | % de respuestas que un experto da por buenas | > 85 % para abrir a usuarios | | Abstención correcta | % de preguntas sin respuesta en el corpus donde el sistema dice «no lo sé» | > 90 % | | Frescura | % de respuestas que citan la versión vigente del documento | 100 % en documentos normativos |

El orden no es casual: si el acierto de recuperación está en el 60 %, cambiar de modelo generador es perder el tiempo. Y la abstención correcta es la métrica que más se ignora y la que más confianza destruye cuando falla: un sistema que dice «no lo sé» el 10 % de las veces es utilizable; uno que nunca lo dice es peligroso, porque el usuario no tiene forma de distinguir la respuesta buena de la inventada.

¿Por qué falla cuando el repositorio está sucio?

Porque el sistema no tiene criterio para saber cuál de tus documentos merece crédito. Hereda el desorden y lo sirve con aspecto de autoridad. Los cuatro patrones que más veces hemos visto:

• Versiones conviviendo. `Politica_gastos_v3_FINAL_revisado_JL.docx` junto a `Politica_gastos_2024.pdf`. Ambos son texto válido; solo uno está vigente y nada en el fichero lo indica.
• Carpetas personales indexadas. Notas, borradores y simulaciones que nunca fueron oficiales entran al índice con el mismo peso que el procedimiento aprobado.
• Permisos que no se replican. El buscador ve todo el repositorio y responde a cualquiera. Un empleado pregunta por bandas salariales y obtiene el anexo de retribución. No es un fallo de IA: es un fallo de control de acceso que el buscador ha hecho visible.
• Documentos sin dueño. Nadie responde de si están al día. Es exactamente el problema que describimos en calidad de datos, trasladado al documento: un PDF correcto en 2022 y nunca revisado es información falsa con formato de información buena.

El trabajo previo que sí merece la pena, y que suele ocupar más tiempo que el desarrollo:

1. Decidir el alcance por valor, no por volumen. Un dominio, un departamento, unos cientos de documentos. Indexar «todo el disco de red» garantiza ruido y garantiza un incidente de permisos. 2. Marcar vigencia. Cada documento indexado necesita, como mínimo, fecha y estado. Si no se puede automatizar, se hace a mano para el alcance elegido: es el mejor dinero del proyecto. 3. Excluir explícitamente. Borradores, personales, papeleras y copias de seguridad fuera del índice desde el primer día. 4. Replicar permisos en la recuperación. Cada usuario solo debe poder recuperar fragmentos de documentos a los que ya tiene acceso. Se filtra antes de buscar, no después de generar. 5. Fijar la fuente de verdad. Si hay dos sitios donde vive la misma política, el proyecto de buscador es la ocasión perfecta para cerrar uno. Es gobierno del dato aplicado a documentos.

Si además vas a indexar documentos con datos personales —expedientes, nóminas, historiales— hay decisiones que tomar antes de escribir una línea de código: dónde se procesa, qué se registra de cada consulta y qué base legal ampara el tratamiento. Está desarrollado en RGPD e IA.

¿Cómo montar el primero en 90 días?

Una ruta que hemos visto funcionar, sin equipo dedicado a tiempo completo y con una persona de negocio implicada de verdad.

| Semanas | Qué se hace | Entregable | |---|---|---| | 1-2 | Elegir un dominio con dolor real y dueño identificable | Alcance escrito: qué carpetas entran y cuáles no | | 3-4 | Construir el conjunto de preguntas de referencia con respuestas | 50-150 preguntas con documento y apartado | | 5-6 | Ingesta, extracción y troceado respetando estructura | Índice construido y medido con las preguntas | | 7-8 | Ajuste de recuperación: híbrido, filtros por metadato, reordenación | Acierto de recuperación por encima del 90 % | | 9-10 | Generación con citas obligatorias y abstención | Respuestas trazables a párrafo | | 11-12 | Piloto con 10-15 usuarios reales y registro de fallos | Decisión con datos: ampliar, ajustar o parar |

Dos detalles que separan el piloto que sobrevive del que muere de éxito. El primero: la cita visible y clicable no es un adorno, es el mecanismo que permite al usuario verificar en cinco segundos y el que hace que el sistema se gane la confianza. El segundo: un botón de «esta respuesta está mal» que genere un registro con la pregunta, la respuesta y los fragmentos recuperados. Sin ese registro no hay mejora posible, solo opiniones; es el mismo motivo por el que muchos pilotos se quedan por el camino, como analizamos en por qué fracasan los pilotos de IA.

Sobre el coste, sin cifras de catálogo: el gasto recurrente de un buscador de este tipo lo marcan el volumen de consultas y el tamaño del índice, no el número de documentos indexados una vez. Lo que suele desviarse del presupuesto no es la factura de infraestructura, sino las horas de limpieza y marcado de vigencia que nadie planificó. Conviene estimarlas mirando una muestra real antes de firmar nada; el marco general está en qué cuesta un proyecto de IA.

Preguntas frecuentes

¿Cuántos documentos hacen falta para que merezca la pena?

Menos de los que la gente imagina. Con 200 o 300 documentos bien elegidos y consultados a diario por varias personas ya hay caso; el valor lo da la frecuencia de consulta y el coste de no encontrar, no el volumen del archivo. Al revés sí hay un límite práctico: indexar cien mil documentos sin metadatos de vigencia produce un sistema rápido y poco fiable.

¿Puede el buscador inventarse una respuesta?

Puede, y lo hará si no recupera el fragmento adecuado y no está configurado para abstenerse. Se mitiga con tres medidas combinadas: exigir cita obligatoria para cada afirmación, permitir explícitamente el «no encuentro esto en la documentación» y medir la abstención correcta en el conjunto de referencia. Eliminarlo del todo no es realista; hacerlo raro y detectable, sí.

¿Los documentos salen de la empresa?

Depende de la arquitectura que elijas, y es una decisión de negocio antes que técnica. Se puede montar con proveedores que no retienen datos, en la nube europea con acuerdos de tratamiento firmados o en infraestructura propia con modelos abiertos, con más coste y más mantenimiento. Lo que no es aceptable es no saber la respuesta: pregúntala por escrito a cualquier proveedor antes de subir un solo fichero.

¿Esto sustituye al gestor documental?

No. Un gestor documental guarda, versiona y controla permisos; el buscador consulta. De hecho, cuanto mejor sea el gestor —con versión única, estados y permisos bien puestos—, mejor funcionará el buscador, porque le da los metadatos que necesita para filtrar. Montar el buscador sobre carpetas compartidas sin estructura es posible, pero se paga en limpieza manual.

Si estás valorando un buscador interno sobre tus documentos, el primer paso útil no es una prueba de concepto con tres PDF: es mirar un dominio real, contar cuántas versiones conviven, cuántos documentos tienen fecha de vigencia y cuánto tarda hoy alguien en encontrar una respuesta. Eso es la auditoría, y sale con una estimación honesta de cuánto trabajo previo hay antes de que la IA aporte algo. Si prefieres contrastarlo en media hora, hablemos y te decimos con franqueza si tu caso es de buscador, de orden documental o de las dos cosas en ese orden.