Cómo evaluar agentes de investigación de IA de código abierto

Los agentes de investigación de IA de código abierto prometen más control que un servicio cerrado de respuestas, pero la disponibilidad del código fuente es solo el comienzo de una evaluación útil. Un repositorio puede exponer su código y aun así dejar sin respuesta preguntas importantes: qué evidencia produjo un resultado, qué datos cruzaron un límite de red, si otro investigador puede volver a ejecutar el flujo de trabajo y cuánto trabajo operativo debe absorber la institución.

Por tanto, una evaluación sólida empieza por la práctica de investigación, no por un recuento de funciones. El objetivo es determinar si un agente hace que un flujo de trabajo real sea más fácil de inspeccionar, repetir, gobernar y mantener. AIPOCH Open Science es un caso de estudio útil porque combina gestión de literatura, agentes, notebooks, conectores científicos, archivos de proyecto y computación remota en una aplicación de escritorio local-first. Su diseño ilustra tanto el potencial de un espacio de trabajo inspeccionable como la brecha entre la actividad registrada y la ciencia reproducible.

Defina la unidad de evaluación

No evalúe un agente de investigación preguntando únicamente si puede responder una pregunta difícil. Primero defina la unidad completa de trabajo. Puede incluir descubrir artículos, adjuntar registros de fuentes, preparar código, seleccionar datos, ejecutar un notebook, enviar un trabajo al clúster, recopilar resultados, producir una figura y documentar revisiones. Un informe fluido es una salida dentro de esa cadena, no la cadena en sí.

Enumere los artefactos y las decisiones que un revisor cualificado necesitaría examinar. Habitualmente incluyen las entradas originales, citas, scripts generados, estado del notebook, registros de ejecución, detalles del entorno, selección de modelo, llamadas externas, archivos intermedios, salidas finales y hallazgos del revisor. Después compruebe si el producto conserva las relaciones entre ellos. Una carpeta llena de archivos es menos útil que un registro que muestra qué entradas, código y ejecución produjeron una versión concreta de un resultado.

La documentación técnica de AIPOCH describe proyectos persistentes que contienen conversaciones, archivos, notebooks de Python y R, registros de ejecución, vistas previas y procedencia de artefactos. La versión 0.26.0 también conecta una biblioteca de referencias con ejecución directa por SSH o Slurm en ordenadores remotos registrados. Esa amplitud solo es relevante si los vínculos sobreviven a los cambios ordinarios de investigación: prompts revisados, análisis alternativos, trabajos interrumpidos, fuentes reemplazadas y salidas actualizadas.

Trace el límite real de control

“Local-first” debe tratarse como una cuestión que investigar, no como una conclusión completa sobre privacidad. El estado del proyecto puede permanecer en un ordenador local mientras los prompts, el contexto, las consultas de búsqueda o los parámetros de tareas viajan a un proveedor de modelos seleccionado, una base de datos científica, un repositorio o un clúster remoto. El límite de control significativo es la ruta completa que sigue la información.

Para cada flujo de trabajo, dibuje dónde comienzan los datos, qué componente los recibe, qué credenciales se utilizan, qué sale del dispositivo y dónde se almacenan los resultados. Repita el ejercicio para las extensiones. Una habilidad reutilizable puede ejecutar código, mientras que un conector puede enviar parámetros a un servicio externo. El código abierto hace posible la inspección, pero no realiza esa inspección por el usuario.

AIPOCH expone la elección de modelo, conectores, ordenadores remotos y políticas de aprobación para acciones como comandos, cambios de archivos y llamadas de red. Esto puede ayudar a una institución a alinear la herramienta con sus propios proveedores e infraestructura. También transfiere trabajo a la institución: alguien debe revisar configuraciones, verificar endpoints, mantener credenciales, comprender el comportamiento de las extensiones y decidir qué acciones merecen permiso persistente.

Incluya controles específicos de la plataforma en la evaluación. Las notas de la v0.26.0 de AIPOCH indican que los controles de red de los notebooks se aplican de forma predeterminada en macOS y Linux, mientras que Windows necesita una configuración administrativa única. La misma documentación de lanzamiento señala que sus instaladores de Windows no están firmados con Authenticode. Ningún detalle determina si la herramienta es adecuada, pero ambos pueden afectar la política de despliegue y el esfuerzo de soporte.

Siga un resultado desde la afirmación hasta la evidencia

Un agente de investigación útil debería permitir a un revisor retroceder desde una conclusión hasta la evidencia y las operaciones que la sustentan. Seleccione un resultado representativo, como una tabla derivada de un análisis o una afirmación derivada de varios artículos, e intente reconstruir su linaje sin depender de la memoria del operador original.

AIPOCH proporciona un modelo concreto para esta prueba. Su sistema de artefactos puede conservar versiones inmutables y sumas de verificación, mientras que su vista de procedencia puede asociar una salida con entradas disponibles, código, registros de ejecución, información de entorno, contexto de conversación y hallazgos de revisión. Su versión anterior 0.8.0 también introdujo ramas para rutas alternativas de conversación. Juntas, estas características pueden hacer visibles los cambios en lugar de reemplazar silenciosamente un estado anterior.

La evaluación debe seguir separando la retención de evidencia de la validez científica. Una suma de verificación puede mostrar que un archivo cambió o no cambió; no puede mostrar que el método fuera apropiado. Un registro de ejecución puede mostrar qué código se ejecutó; no puede establecer que los supuestos estadísticos fueran sólidos. Un registro de cita puede identificar un artículo; no puede demostrar que el agente lo interpretó correctamente. La inspeccionabilidad crea una mejor superficie para la revisión experta, no una verdad automatizada.

Use varias preguntas orientadas al fallo. ¿Puede el revisor identificar qué rama produjo el artefacto publicado? ¿Puede ver si se reemplazó una fuente? ¿Puede distinguir el código generado del código ejecutado? ¿Puede indicar qué resultados provinieron de un trabajo remoto? ¿Puede conservar una corrección del revisor sin borrar la salida original? Las respuestas débiles revelan lagunas de procedencia con más fiabilidad que una demostración pulida.

Separe auditabilidad de reproducibilidad

La auditabilidad pregunta si el proceso puede examinarse. La reproducibilidad pregunta si se capturó suficiente estado para ejecutarlo de nuevo y obtener un resultado comparable. Un agente puede rendir bien en el primer estándar y seguir siendo incompleto en el segundo.

Una revisión de reproducibilidad debe buscar entradas identificadas, bloqueos de dependencias, detalles de paquetes y sistema operativo, estados aleatorios, orden de ejecución, información de modelo y proveedor, configuración remota e identidades de conjuntos de datos externos. También debe registrar lo que no puede congelarse. Los proveedores de modelos pueden cambiar el enrutamiento o la implementación, las bases de datos científicas pueden actualizarse y los clústeres remotos pueden diferir en hardware o bibliotecas. Registrar solo un nombre de modelo o una transcripción de conversación no elimina esas variables.

AIPOCH presenta explícitamente la restauración portable del entorno y la repetición completa de sesiones como trabajo sin terminar. Ese es un límite importante, no una omisión menor. Sus artefactos conservados y su procedencia pueden respaldar la investigación hoy, pero no deben describirse como prueba de reconstrucción determinista. Una evaluación debe registrar esta distinción en la propia decisión para que los usuarios sepan qué flujos de trabajo aún requieren gestión externa del entorno.

Ejecute una repetición controlada con datos no sensibles. Entregue a una segunda persona cualificada el registro de proyecto conservado, elimine el conocimiento informal y pídale que reproduzca un artefacto. Anote cada dependencia ausente, aprobación no documentada, servicio no disponible, movimiento manual de archivos e instrucción ambigua. La lista de lagunas resultante es más accionable que una afirmación general de que un flujo de trabajo es reproducible.

Lea los benchmarks como evidencia delimitada

Los benchmarks pueden comparar sistemas en condiciones definidas, pero no certifican la calidad de investigación en todas las disciplinas. Antes de aceptar una puntuación, inspeccione la fuente de la tarea, la división pública y privada, el modelo seleccionado, el método de evaluación, el presupuesto de ejecución, la configuración de referencia y la disponibilidad de trazas. Pregunte si un equipo externo puede reproducir la configuración y si la métrica comunicada expone modos de fallo consecuentes.

AIPOCH informa un resultado de 79,05 en la parte pública de BiomniBench-DA usando un modelo concreto y dos jueces automatizados. La ficha de datos del benchmark describe 100 tareas de análisis de datos biomédicos derivadas de publicaciones, con 50 tareas públicas y 50 tareas privadas. Esta es evidencia útil y delimitada sobre trayectorias analíticas de varios pasos. No es una validación en todos los dominios de investigación, modelos, instituciones o conjuntos de datos no publicados.

Dé mayor peso a la replicación independiente y al análisis detallado de fallos que a un único promedio. Los errores de citas, errores de unidades, elecciones estadísticas inapropiadas, interpretaciones inventadas y fallos de recuperación pueden quedar ocultos por una puntuación agregada. Un agente inspeccionable solo tiene ventaja cuando sus registros realmente ayudan a los revisores a localizar y corregir esos fallos.

Pruebe el encaje operativo, no solo la capacidad

La integración puede reducir los traspasos entre herramientas de referencia, interfaces de chat, notebooks, terminales y exploradores de archivos. También amplía la superficie que deben soportar los responsables de mantenimiento. El empaquetado de escritorio, las migraciones de bases de datos, las credenciales, las API de modelos, la ejecución de notebooks, las vistas previas científicas, los conectores y los planificadores de clúster pueden fallar de forma independiente.

El soporte de Slurm de AIPOCH ilustra la distinción entre integración e infraestructura proporcionada. La aplicación de escritorio puede enviar, supervisar, recuperar, cancelar, limpiar y recopilar resultados de trabajos en un host configurado. No convierte un portátil en un entorno de computación de alto rendimiento ni proporciona un servicio de GPU en la nube integrado. Un laboratorio aún necesita computación funcional, controles de acceso, política del planificador y personas capaces de diagnosticar fallos.

Los permisos merecen una prueba de usabilidad basada en tareas. Un issue público de una versión temprana de AIPOCH describía solicitudes repetidas de autorización durante trabajo de escritura de código; el issue se cerró más tarde y versiones posteriores incluyeron cambios de permisos. Este historial no establece el comportamiento actual, pero identifica una prueba productiva: si los avisos se producen en límites de riesgo comprensibles o se convierten en interrupciones rutinarias que los usuarios aprueban automáticamente.

Mida el esfuerzo de instalación, la recuperación de trabajos fallidos, el comportamiento de actualización, la revisión de extensiones, la claridad de los registros y el tiempo necesario para incorporar a un segundo operador. Registre quién se hace cargo de cada tarea tras la adopción. Una herramienta puede ofrecer un control valioso y aun así no ser adecuada si la organización no puede mantener el plano de control que la rodea.

Use una lista de verificación de evaluación por etapas

Empiece con un flujo de trabajo representativo, no sensible y una línea de base establecida. Mantenga el piloto lo bastante acotado para que pueda examinarse cada paso. Después use esta lista de verificación:

1. Defina la pregunta de investigación, los artefactos esperados, la evidencia aceptable y el revisor experto antes de ejecutar el agente.
2. Haga inventario de cada componente local y externo, incluidos modelos, conectores, habilidades, bases de datos, repositorios y ordenadores remotos.
3. Registre qué datos cruzan cada límite y verifique que los permisos coincidan con las normas institucionales.
4. Siga una afirmación final hacia atrás a través de citas, entradas, código, ejecución, archivos intermedios y versiones de artefactos.
5. Cambie un supuesto y confirme que la ruta alternativa siga siendo distinguible de la original.
6. Entregue el registro conservado a un segundo operador y documente cada obstáculo para volver a ejecutar el flujo de trabajo.
7. Inspeccione las condiciones y trazas del benchmark; trate las puntuaciones como evidencia solo para la configuración probada.
8. Introduzca un fallo de ejecución o de red y evalúe recuperación, registros, limpieza e integridad de los artefactos.
9. Revise las extensiones importadas por fuente, licencia, scripts, comportamiento de red, versión y mantenedor.
10. Compare la calidad de salida, el tiempo de revisión, el esfuerzo de configuración, la tasa de fallos y la carga de soporte con el proceso existente.
11. Clasifique las lagunas no resueltas como riesgos científicos, de seguridad, de usabilidad u operativos y asigne un responsable.
12. Apruebe solo los flujos de trabajo cuyas evidencias y controles cumplan el estándar requerido; evite conceder al producto una confianza más amplia de forma predeterminada.

La decisión final debe ser específica. Indique qué tareas puede realizar el agente, a qué datos puede acceder, qué acciones requieren aprobación, qué evidencia debe acompañar una salida y cuándo es obligatoria la revisión humana. Indique también lo que la evaluación no demostró.

Los agentes de investigación de código abierto son más valiosos cuando hacen que el trabajo consecuente sea más fácil de cuestionar. AIPOCH muestra cómo los registros de literatura, los notebooks, la ejecución remota, las ramas y la procedencia de artefactos pueden reunirse en un espacio de trabajo inspeccionable. También muestra por qué un repositorio abierto, una puntuación de benchmark o un flujo de trabajo visible no bastan por sí solos. El estándar duradero es si otra persona cualificada puede comprender la ruta, cuestionar el método, volver a ejecutar lo que pueda volver a ejecutarse y operar el sistema dentro de límites institucionales claros.