Búsqueda de conocimiento interna con citas
Los equipos de finanzas, seguros y servicios profesionales suelen tener conocimiento valioso repartido entre PDFs, carpetas, presentaciones, documentos de políticas y materiales de proyectos antiguos. La búsqueda existe, pero encontrar la respuesta correcta sigue llevando demasiado tiempo.
La búsqueda de conocimiento con IA puede ayudar, pero solo si la respuesta está ligada a las fuentes. Un modelo que responde con fluidez sin citar es un riesgo en cualquier equipo donde la respuesta equivocada tiene un coste regulatorio o contractual. El trabajo técnico no es solo "construir un chatbot": es construir un sistema de recuperación que el equipo pueda auditar.
Por qué importan las citas
Una respuesta sin fuente es difícil de creer. Un sistema interno de conocimiento útil debería mostrar qué documentos se usaron, de dónde salió la respuesta y qué debería verificar el usuario.
Esto importa en los equipos sensibles al cumplimiento normativo porque la IA debe apoyar el trabajo, no inventar políticas. Las citas también cambian el modo de fallo: cuando el modelo se equivoca, el usuario puede ver por qué: normalmente porque el fragmento recuperado estaba desactualizado, era ambiguo o no venía al caso. Esa visibilidad diagnóstica es lo que convierte un sistema de conocimiento de una caja negra en una herramienta que el equipo puede mejorar.
Un contrato de citas viable para el objeto de respuesta:
```json
{
"answer": "...",
"citations": [
{
"doc_id": "policy-2024-03",
"title": "Underwriting Guidelines 2024",
"page": 17,
"snippet": "...",
"score": 0.82,
"version": "rev-3",
"approved_at": "2024-03-12"
}
],
"confidence": 0.74,
"unresolved": false
}
```
Cada respuesta debería ser reproducible: misma pregunta, misma versión indexada, mismas citas. Si el sistema no puede reproducir su propia salida, el equipo no puede defenderla.
Un buen primer alcance
El primer sprint debería centrarse en una colección de documentos y un equipo.
Indexar documentos aprobados
Buscar en lenguaje natural
Devolver resúmenes de respuesta con citas
Mostrar fragmentos de la fuente
Registrar las preguntas y el contenido que falta
Esto crea un piloto seguro antes de ampliar a más repositorios.
Una arquitectura base práctica para el primer sprint:
Ingesta. Un worker que extrae de una fuente (SharePoint, Google Drive, S3 o una carpeta de red), aplica OCR donde haga falta (Tesseract, Azure Document Intelligence o AWS Textract para PDFs escaneados) y escribe markdown normalizado en almacenamiento de objetos.
Troceado. Divisiones conscientes de la estructura (encabezado, párrafo, tabla), de 400-800 tokens, con solapamiento solo donde la estructura se rompe. Guarda junto a cada fragmento el número de página original, el encabezado de sección y la versión del documento.
Embeddings y almacenamiento. OpenAI `text-embedding-3-large` o un modelo comparable, escrito en pgvector o una base de datos vectorial gestionada (Pinecone, Weaviate, Qdrant). Mantén el texto en bruto y los metadatos en Postgres para que el fragmento siempre pueda reconstruirse.
Recuperación. Búsqueda híbrida: BM25 (full-text de Postgres u OpenSearch) más similitud vectorial, y después un re-ranker (Cohere Rerank o un modelo cross-encoder) sobre los 30 mejores candidatos.
Generación. Un prompt pequeño que toma los 5-8 mejores fragmentos y produce una respuesta con citas inline obligatorias. Rechaza cualquier salida que cite un `doc_id` que no esté en el conjunto recuperado.
Interfaz. Una app mínima en Next.js o Streamlit que muestre la respuesta, los chips de citas y una vista previa de cada fragmento citado al pasar el cursor.
El control de acceso no es opcional. Cada fragmento debería llevar los mismos permisos que su documento de origen, y el paso de recuperación debe filtrar por el acceso del usuario que pregunta antes de la generación. "El modelo resumió por accidente un archivo confidencial" es un incidente mucho más caro que una respuesta que falta.
Qué medir
Mide el tiempo hasta la respuesta, la utilidad de las citas, las preguntas repetidas, los documentos que faltan y la confianza de los usuarios.
Métricas concretas que se sostienen en un piloto:
Precisión de las citas. De las citas que devuelve el modelo, ¿cuántas contienen de verdad la afirmación citada? Muestrea 50-100 respuestas por semana y etiquétalas a mano durante el primer mes.
Cobertura de respuestas. De las preguntas reales de los usuarios, ¿cuántas produjeron una respuesta con al menos una cita válida, frente a "no lo sé"? "No lo sé" es una funcionalidad, no una regresión: mídelo, pero no lo penalices.
Principales temas sin respuesta. Agrupa las preguntas sin respuesta; son los huecos del corpus documental, y a menudo valen más que las propias respuestas.
Tasa de corrección del revisor. Cuando un revisor experto lee la respuesta de la IA, ¿con qué frecuencia la edita o la rechaza? Una tasa de corrección que baja es la señal más clara de que el sistema se está ganando la confianza.
Latencia. P50 y P95 de extremo a extremo. Menos de 4-6 segundos para una respuesta totalmente citada es un objetivo razonable en un corpus moderado.
Si la gente confía en las fuentes, el sistema puede convertirse en un asistente interno práctico en lugar de otra caja de búsqueda más. El camino hacia esa confianza es aburrido y concreto: corpus pequeño, recuperación sólida, citas obligatorias, modos de fallo visibles y un ciclo de mejora semanal medible.