Investigación independiente · Agosto de 2026 · Edition 0.2
Investigación independiente
Pablo CardozoIngeniero · Technical PartnerBuenos Aires, ArgentinaGitHub · LinkedIn
Resumen
Estos papers nacieron de sistemas que construí y después revisé con más cuidado. Cada uno identifica la revisión fuente, separa resultados observados de trabajos todavía no ejecutados y mantiene visibles los tests fallidos o ausentes. Los temas son memoria conversacional, evaluación de un agente para restaurantes y extracción estructurada de catálogos. Es trabajo independiente, sin afiliación académica ni peer review.
Palabras clave: modelos de lenguaje; diseño de evaluaciones; memoria conversacional; extracción estructurada; reproducibilidad; análisis de fallas
1. Papers
Son manuscritos completos, no resúmenes de una página. Cada uno incluye el método, las limitaciones, las referencias y un PDF para descargar. Los PDFs actuales tienen ocho o nueve páginas.
La memoria persistente transforma a un agente conversacional sin estado en un sistema que almacena y luego recupera hechos específicos de cada usuario. En un despliegue multi-tenant, la calidad de recuperación y la privacidad quedan acopladas: una respuesta puede ser verosímil y aun así constituir una falla si su evidencia pertenece a otro tenant. Este working paper analiza un runtime orientado a producción conectado a WhatsApp que combina estado del hilo, memoria vectorial y recuperación documental basada en grafos. Formaliza cuatro invariantes —escrituras aisladas por tenant, recuperación aislada, evidencia negativa contra filtraciones y borrado completo— y los vincula con un benchmark ejecutable de seis consultas. El runner versionado crea dos tenants sintéticos, escribe hechos mutuamente excluyentes, puntúa evidencia léxica obligatoria y prohibida, y reporta exactitud y latencias contra objetivos declarados. El protocolo existe; no existe todavía un resultado versionado de una ejecución real. Por eso este trabajo no afirma que el sistema desplegado cumpla los objetivos. Su aporte es un modelo de amenazas falsable, una auditoría de lo que el artefacto actual puede demostrar y un plan de extensión con paráfrasis, contradicciones, actualizaciones, recuperación diferida, borrado y ablaciones. La conclusión central es metodológica: la memoria multi-tenant debe evaluarse como un problema de aislamiento con afirmaciones positivas y negativas, no solo como exactitud de recuperación.
Pregunta de investigación
¿Puede un agente multi-tenant recuperar hechos persistentes sin exponer hechos de otro tenant, y puede evaluarse esa afirmación con un protocolo inspeccionable?
Grado de evidencia
Grado P — evidencia de protocolo, no afirmación de resultado
Datos rastreables
Artefacto: 2 tenants · 6 consultas · 3 tipos de hecho · Regla de decisión: 6/6 correctas y p95 ≤ 700 ms · Límite: Sin resultado público de ejecución · Fuente: Revisión privada 1470f8f17163
Este informe audita un harness LLM-as-a-Judge para un asistente transaccional de restaurantes. El artefacto guardado contiene 46 casos y registra 40 aprobados con umbral 75/100, score promedio 80, 671,3 segundos totales y 28.010 tokens del juez. El desempeño no es uniforme: fallan los cinco casos de pago y un caso FAQ; las otras diez categorías reportan aprobación completa o casi completa. La concentración de fallas es más útil que el 87% agregado porque identifica un defecto de ruteo de estado en la frontera de pagos. La auditoría encuentra además tres límites importantes. Primero, los casos “meta” de seguridad y resiliencia se envían como mensajes al chatbot y se puntúan por plausibilidad conversacional; no ejecutan el comportamiento HTTP, rate-limit, retry o circuit breaker que nombran. Segundo, la batería versionada en la revisión fuente contiene casos adicionales ausentes en la salida de 46, por lo que la corrida no puede tratarse como ejecución limpia del árbol actual. Tercero, no hay calibración humana, semillas repetidas ni reejecución independiente. La verificación local del 4 de agosto de 2026 confirmó 36 assertions de la batería y 43 del asistente, pero Vitest no terminó limpiamente porque quedaron handles abiertos; no se repitió la corrida end-to-end del juez. Por eso los scores se tratan como evidencia del repositorio, no como verdad de terreno, y se propone una evaluación en tres capas: checks deterministas para estado y seguridad, revisión con modelo para diálogo abierto y calibración humana ciega.
Pregunta de investigación
¿Puede un juez automático por categorías exponer clusters accionables de fallas en un agente multi-turn, y qué falta para que sus scores sean evidencia confiable?
Grado de evidencia
Grado R — resultado del repositorio, sin reejecución end-to-end independiente
Datos rastreables
Corrida guardada: 40/46 · promedio 80/100 · Cluster de fallas: 5 pagos · 1 FAQ · Ejecución: 671,3 s · 28.010 tokens · Check local: 79 assertions; proceso no cerró
Los catálogos de productos en PDF y planillas combinan layout visual, descripciones abreviadas, convenciones de packaging, precios, descuentos y límites de fila inconsistentes. Un único prompt puede devolver JSON válido y aun así omitir filas, fusionar productos o inventar procedencia. Este protocolo estudia un pipeline implementado de tres etapas que separa metadata documental, reconstrucción de filas fuente y normalización de productos. Cada etapa está restringida por schemas. La etapa final procesa lotes de diez filas y debe repetir una identidad de lote determinista, el conjunto exacto de identificadores y la cobertura de páginas antes de persistir. El post-procesamiento fuerza a revisión humana los productos ambiguos, de baja confianza o no normalizables. El 4 de agosto de 2026 se fijó la revisión registrada y la suite local completa aprobó 569 tests en 20 archivos en 1,06 segundos. También aprobaron cinco tests de performance, pero simulan inserción con un array en memoria y no aportan evidencia sobre throughput de Convex, del modelo ni end-to-end. No existe en los artefactos inspeccionados un corpus etiquetado, baseline de una pasada, predicciones crudas ni resultado de exactitud. El aporte es doble: auditoría reproducible de los controles de procedencia y diseño falsable para comparar el sistema con un baseline fijado. Las métricas separan detección de filas, normalización, filas inventadas, atribución, carga de revisión, latencia y costo. No se afirma que la descomposición mejore exactitud hasta ejecutar el experimento.
Pregunta de investigación
¿Separar comprensión documental, reconstrucción de filas y normalización mejora la confiabilidad frente a una extracción de una sola pasada?
Grado de evidencia
Grado S/P — evidencia de software reproducida y protocolo experimental sin ejecutar
Datos rastreables
Suite local: 569/569 tests · 20 archivos · Duración: 1,06 s con Node 24.14.0 · Pipeline: 3 etapas · lotes de 10 filas · Exactitud: No medida en corpus etiquetado
El código puede demostrar que un sistema existe. Por sí solo, no demuestra que una afirmación de investigación sea cierta. Los grados de abajo indican qué respalda cada artefacto.
Grado
Significado
Qué permite afirmar
P · Protocolo
Pregunta falsable, diseño de dataset, métricas, umbrales y plan de publicación.
Afirmaciones sobre el diseño; ninguna afirmación de resultado.
R · Resultado de repositorio
Corrida o medición preservada e inspeccionada en una revisión fijada.
Reportar el artefacto y sus límites; no afirmar reproducción independiente.
S · Software reproducido
Suite determinista reejecutada localmente en la revisión declarada.
Afirmaciones limitadas a las propiedades codificadas por esos tests.
3. Estándar de publicación
Considero que un paper está listo para submission cuando otra persona puede inspeccionar la pregunta, el entorno, la comparación, las métricas, las salidas crudas y las condiciones de falla. Los datos fuente deben estar versionados y la reproducción tiene que funcionar desde un checkout limpio. Antes de enviarlo también quiero una revisión técnica externa al proyecto. Los tests fallidos y los experimentos pendientes quedan en el paper.
4. Autoría y uso de herramientas
Usé modelos de lenguaje durante el desarrollo de software, el análisis de repositorios y la edición. Elegí los sistemas y el material fuente, tomé las decisiones experimentales, revisé las interpretaciones y sigo siendo responsable por las correcciones y afirmaciones públicas. Tener un repositorio no me convierte en autor del trabajo sustantivo de otra persona.
Pablo Cardozo · Technical Partner · Investigador independiente · Buenos Aires, Argentina