Prueba y compara con justicia sistemas de búsqueda que dan memoria a agentes de IA

## Afirma solo lo que muestran los resultados de la prueba Distingue las afirmaciones sobre todo el sistema de las afirmaciones sobre una función. Para afirmar que un sistema de recuperación completo es el mejor, hacen falta pruebas de calidad de recuperación, memoria de contexto largo, calibración, fiabilidad, coste y comportamiento operativo. Ninguna función o prueba comparativa individual puede demostrarlo. Al evaluar una función, pregunta si aporta un valor significativo a los usuarios del sistema. No dediques la evaluación a demostrar que un algoritmo propietario supera a otro cuando la decisión sobre el producto depende de los resultados para los usuarios. Antes de ejecutar un experimento, escribe la afirmación, la unidad de análisis, el efecto esperado, el umbral de decisión y las condiciones que impedirían generalizar el resultado. Rechaza las conclusiones cuyo alcance sea mayor que la población, carga de trabajo, motor o configuración probados. ## Elige por separado la base de datos y la fuente dentro de ella Modela el enrutamiento del conocimiento mediante dos ejes independientes: - el corpus o la base de datos que controla el almacenamiento y la política de acceso; - la fuente o colección dentro de ese corpus. Resuelve ambos ejes con una cadena de precedencia explícita, como entrada por llamada, permiso autenticado, contexto de sesión, marcador del repositorio, configuración del usuario y valor predeterminado. Registra los valores resueltos con cada consulta para poder diagnosticar un enrutamiento incorrecto silencioso. Considera no fiables las llamadas remotas o dirigidas a agentes, salvo que la confianza se haya establecido de forma explícita. Aplica el alcance de la fuente a todas las rutas de lectura mediante una única función auxiliar compartida; no construyas filtros manualmente en consultas individuales. Valida los identificadores antes de usarlos en uniones o claves y define la unicidad sobre la clave completa con alcance de fuente. ## Compara los modos de búsqueda con todos sus ajustes juntos Define los modos con nombre como conjuntos coherentes de política de caché, presupuesto de tokens, expansión de consultas, recuperación relacional, ponderación de intención y límite de resultados. Resuelve la configuración mediante una cadena determinista, con las anulaciones por llamada por encima de la configuración del despliegue y una alternativa documentada. Compara los modos como opciones completas para el usuario en vez de escoger solo un ajuste favorable. Informa del valor activo y de su origen para cada ajuste. Aplica la resolución del modo en la ruta de búsqueda compartida de nivel más bajo para que las consultas de producción y las repeticiones de evaluación recorran el mismo comportamiento. Cuando una nueva rama de recuperación solo se aplique a un tipo de consulta reconocido, haz que sea determinista y que no realice ninguna operación en los demás casos. Proporciona una anulación por consulta para realizar experimentos controlados sin cambiar el valor predeterminado de todo el sistema. ## Calcula el coste con niveles de uso reales Calcula el coste posterior a partir del volumen de consultas, los tokens de contexto entregados, el precio de entrada del modelo, las llamadas de expansión y la tasa de aciertos de caché. Muestra al menos niveles de uso ligero, típico e intensivo para que los lectores puedan escalar el resultado sin extrapolar a partir de una sola consulta. Separa el coste aislado por consulta del gasto real de un bucle de agente. La caché de instrucciones, los aciertos de la caché de recuperación, los cambios en el prefijo y las llamadas repetidas a herramientas pueden modificar considerablemente el total real. Indica qué ahorros se han medido, cuáles se han supuesto y cuáles se han excluido. Evalúa el modo y el modelo posterior como una pareja. Un contexto sobredimensionado puede saturar un modelo de baja capacidad, mientras que un presupuesto demasiado restrictivo puede dejar sin información a un modelo caro. Prefiere combinaciones naturales y señala las incompatibilidades como modos de fallo distintos en vez de ordenar solo por coste. ## Decide qué medir y cómo juzgarlo antes de probar Para cada métrica presentada, publica una definición en lenguaje sencillo junto al resultado legible por máquinas. Utiliza un glosario canónico para términos como precisión en un punto de corte, ganancia descontada, rango recíproco, solapamiento, calibración, latencia y coste. Antes de recopilar resultados, especifica los conjuntos de datos, la selección de muestras, la dirección esperada, las métricas principales, las amenazas a la validez y las reglas de exclusión. En comparaciones emparejadas, utiliza un método de remuestreo emparejado y corrige las comparaciones múltiples al probar varias métricas o variantes. Conserva tanto resúmenes legibles por personas como metadatos estructurados. No añadas campos de glosario improvisados junto a valores individuales; adjunta un único bloque de metadatos coherente por respuesta para que las herramientas posteriores puedan analizarlo de forma fiable. ## Haz que cualquiera pueda repetir las pruebas de reparto de preguntas Separa los casos de entrenamiento de los casos reservados para evaluación. Puntúa con criterios estrictos y también con criterios flexibles documentados de forma explícita cuando una variación de formato pueda ocultar un enrutamiento semánticamente correcto, pero no cambies los criterios después de ver los resultados reservados. Para cada ejecución entre modelos, guarda un recibo que vincule el identificador del modelo, el hash de la plantilla de instrucciones, el hash de los casos, la revisión del entorno de evaluación, la marca de tiempo y la versión de puntuación. Conserva las predicciones sin procesar para poder mejorar o auditar la lógica de puntuación sin pagar por volver a ejecutar el modelo. Utiliza ablaciones para identificar las señales esenciales. Retira una cláusula de enrutamiento, una capa jerárquica o un campo de contexto cada vez y compara con el mismo conjunto reservado. Una caída del rendimiento respalda una afirmación causal de diseño; una anécdota no emparejada de antes y después no lo hace. ## Evita que los resultados guardados (caché) se mezclen entre ajustes Incluye en la clave de caché todas las entradas que cambien el comportamiento: alcance de la fuente, ajustes del modo, límite de resultados, estado de expansión, ramas y profundidad de recuperación, proveedor de representaciones vectoriales, columna o modelo de representación y cualquier indicador de función que altere la clasificación. Versiona el contrato de la clave de caché. Cuando cambie la semántica, incrementa la versión para que las filas antiguas dejen de ser accesibles mediante un fallo de caché normal en vez de interpretarse con la configuración nueva. Prueba el aislamiento entre modos, fuentes y proveedores, así como entre la recuperación relacional activada y desactivada. Ejecuta pruebas de paridad en todos los motores de almacenamiento compatibles, porque un motor integrado puede ocultar comportamientos de codificación o tipos que solo aparecen en una base de datos de producción. ## Protege los datos privados y explica los arreglos de seguridad sin revelar puntos débiles Guarda los registros de evaluación en el área de auditoría del proyecto, nunca en el corpus privado activo de un usuario. Utiliza nombres y organizaciones sintéticos en casos, ejemplos, informes, notas de versión y debates públicos. Sustituye las consultas que revelen relaciones por marcadores genéricos. Describe funcionalmente las correcciones de seguridad en materiales públicos. Explica el mecanismo de protección y la acción requerida al operador sin publicar una lista preparada de registros sensibles, la duración de la exposición ni la ruta de sondeo más sencilla para sistemas sin corregir. Mantén el análisis detallado de la exposición en pruebas de revisión con acceso restringido. Antes de publicar, pregunta si una persona sin contexto previo podría deducir relaciones privadas o atacar directamente un despliegue antiguo; si es así, generaliza la redacción. ## Mantén los documentos de investigación al día y breves con revisiones automáticas Utiliza una estructura documental por capas: - una orientación cargada siempre que contenga el objetivo de investigación, el modelo de enrutamiento, la arquitectura y las invariantes transversales; - documentos de referencia del estado actual que se carguen solo para el subsistema correspondiente; - un registro de cambios y un historial de versiones para el comportamiento pasado. No añadas una narración versión por versión a las referencias de estado actual. Actualiza la entrada existente con la nueva realidad y conserva los detalles históricos en el control de versiones y el registro de cambios. Aplica en la integración continua límites de tamaño, marcadores históricos prohibidos, vigencia del glosario generado y vigencia del conjunto documental. Una regla escrita sin una protección automatizada no constituye una restricción duradera. ## Guarda toda la salida y los ajustes de cada ejecución Escribe el progreso en un canal separado de los resultados de datos. Mantén estables los nombres de fase, convierte el progreso estructurado en una opción explícita y asegura que las operaciones largas emitan señales de actividad sin corromper los resultados legibles por máquinas. En pruebas y evaluaciones, captura el resultado completo en un archivo antes de mostrar una parte final o un resumen filtrado. Registra el código de salida del comando original antes de ejecutar cualquier visor. Nunca canalices una puerta de validación directamente mediante un comando que trunque contenido, porque la canalización puede informar del éxito del visor mientras descarta los detalles del fallo real. Cada ejecución debe conservar la configuración, el modo resuelto, la identidad del conjunto de datos, los hashes, las métricas, el coste, las advertencias, el estado de salida y las marcas de tiempo. Un resultado solo sirve para tomar decisiones cuando otra persona revisora puede reconstruir lo ejecutado y distinguir los hechos medidos de las suposiciones.