Aconsejar ante un ticket nunca visto
con años de incidencias
Esa memoria ya la habías pagado.
Ese archivo lo tiene cualquier equipo que lleve años resolviendo incidencias; lo raro
es usarlo bien cuando entra el siguiente caso nunca visto.
la consulta, en directo
Dos tickets reales del test ciego, tal cual salieron. Elige uno y mira qué hizo el
sistema. Los títulos y las citas van en su idioma original, en inglés.
consulta
responde citando
entraFLINK-35848 · [Release-1.20] Vote on the release candidate
responde (extracto)
Este ticket es una tarea estándar del proceso de release de Apache Flink (release 1.20): iniciar y gestionar el hilo de votación [VOTE] en la lista [email protected] para el release candidate. No es un incidente técnico, sino un paso operativo del release. Los análogos recuperados (…) son exactamente la misma tarea de "Vote on the release candidate" y muestran cómo se resolvieron.Este ticket es una tarea estándar del proceso de release de Apache Flink (release 1.20): iniciar y gestionar el hilo de votación [VOTE] en la lista [email protected]para el release candidate. No es un incidente técnico, sino un paso operativo del release. Los análogos recuperados (…) son exactamente la misma tarea de "Vote on the release candidate" y muestran cómo se resolvieron.
"The vote will be open for at least 72 hours. It is adopted by majority approval, with a…"
La resolución real coincide en sustancia. Los dos jueces automáticos, a ciegas el uno del otro: acierto pleno.
se abstiene
entraFLINK-35408 · Add 30 min tolerance value when validating the time-zone setting
responde
No encuentro en el histórico casos suficientemente parecidos a este ticket. ¿Puedes indicar la versión exacta de Flink, el componente afectado y el mensaje de error completo (stacktrace) para poder ayudar con más precisión?No encuentro en el histórico casos suficientemente parecidos a este ticket. ¿Puedes indicar la versión exacta de Flink, el componente afectado y el mensaje de error completo (stacktrace) para poder ayudar con más precisión?
el motivo
Sin casos análogos ni evidencia suficiente. En vez de inventar una propuesta floja, pide contexto.
Los dos jueces coincidieron: abstención correcta. Abstenerse sin evidencia también es acertar. Es lo que lo distingue, no un defecto.
El consejo viene siempre con los casos que lo justifican; puedes ir a la fuente y
comprobarlo. Abstenerse, cuando no hay base, también es acertar.
resumen
los datos
El sistema de tickets (Jira) del proyecto Apache Flink, público: la misma aplicación de ticketing que usa cualquier empresa, con casi doce mil incidencias resueltas y documentadas.
la pregunta
Toda empresa guarda años de tickets: problemas que llegaron y cómo se resolvieron. ¿Puede esa memoria aconsejar cuando llega un problema nuevo?
la prueba
El sistema solo conoce los tickets viejos. Le enseñamos tickets nuevos que nunca vio, sin su solución, y le pedimos consejo. Después comparamos con la solución real.
lo que salió
El consejo del sistema fue útil en 8 de cada 10 casos evaluados. Y cuando no tenía base, el sistema decía "no lo sé", que también es acertar.
Todas las empresas acumulan el mismo archivo: la cola de tickets. Años de problemas,
discusiones y soluciones, escritos, guardados, y que nadie vuelve a leer. Para esta
demo usamos uno público: un gran proyecto de software con casi doce mil
incidencias resueltas y documentadas.
La pregunta: cuando entra un problema nuevo, ¿puede un sistema usar esa memoria para
aconsejar? Y no hablamos de buscar palabras parecidas. Hablamos de aconsejar: qué
puede estar pasando, por dónde se resolvió esto otras veces, y con cuánta confianza.
Con derecho a abstenerse: preferimos un sistema que dice "no tengo base para opinar"
a uno que opina siempre.
Construimos la memoria solo con los tickets anteriores a una
fecha de corte. Los posteriores se los enseñamos sin su resolución. Escribimos los
criterios de evaluación antes de mirar un solo resultado, y cada respuesta la
puntuaron dos jueces automáticos independientes, de proveedores distintos, que no ven
el razonamiento del otro; cuando discreparon, valió la peor nota.
Lo que salió
Sobre los tickets del futuro que se podían corregir con la lista de criterios
escrita de antemano (la "rúbrica"), el consejo fue útil (acierto pleno o parcial) en el
79,5% de los casos. El sistema se abstuvo con razón en el 9,6% y
falló en el 11%. Y en uno de cada seis tickets que revisó dijo "no tengo base para
opinar", la abstención es parte del diseño, no un defecto.
el embudo
tickets resueltos en el periodo de test934
con resolución reconstruible desde el histórico523
muestreados para evaluación120
evaluables con la rúbrica73
el veredicto sobre los 73 evaluables
32,9% acierto pleno 46,6% acierto parcial 9,6% se abstuvo con razón 11,0% fallo
Consejo útil (pleno + parcial): 79,5%. Criterios escritos antes de mirar. La abstención es parte del diseño.
El detalle que más nos gusta: el consejo viene siempre con los casos históricos que lo
justifican. No es un oráculo. Es la memoria del proyecto, ordenada y citada; puedes ir
a la fuente y comprobarlo.
Cómo leer esto sin engañarse
El embudo se publica entero. De 934 tickets resueltos en el periodo de test, 523 tenían resolución reconstruible desde el propio histórico, y de la muestra evaluada, 47 se resolvieron solo con código, sin explicación escrita, esos no se pueden puntuar con la rúbrica.
Aquí sí hay modelos de lenguaje trabajando. Ese es el experimento: consejo en lenguaje natural, con red de seguridad, citas verificables contra la fuente, doble juez automático independiente y abstención obligatoria cuando falta evidencia.
"Útil" tiene definición escrita. Pleno o parcial según una rúbrica de cinco categorías congelada antes de evaluar; los dos jueces automáticos coinciden en el 86% de los casos.
Abstenerse es acertar cuando no hay evidencia. Un consejo sin base no es un consejo: es ruido con buena sintaxis.
Los peros
El juez automático no está contrastado con una calificación humana sistemática; los números son los del test ciego pre-registrado, con la rúbrica congelada de antemano.
Los textos de los tickets proceden del volcado final del sistema, no de una foto congelada en el momento de la resolución: una edición posterior podría colar información. Límite declarado, común a todo archivo vivo.
Es un proyecto de desarrollo de software, no un servicio de soporte: el 39-44% de los casos se resuelven solo con código. En un archivo de soporte real esa fracción cambia, y la demo habría que repetirla allí.
Es una muestra evaluada con rúbrica, no un despliegue en producción. Demuestra que la memoria es utilizable, no que un producto concreto funcione.
Referencias
Recomendar soluciones a partir de tickets históricos es un campo con literatura propia
(case-based reasoning, ticket recommendation, retrieval aumentado). Lo que esta
demo añade es el protocolo en público: futuro tapado, criterios congelados antes
de mirar, la abstención tratada como resultado de pleno derecho (no como un fallo) y el
embudo completo publicado.
Datos y agradecimientos
Aquí hay demo porque la Apache Software Foundation trabaja en abierto y su
histórico de incidencias es público. Gracias.
Sin afiliación con la fundación ni con el proyecto analizado. Los autores de los
tickets aparecen seudonimizados en todas las superficies visibles.
¿Puedes usar esto? Sí. Nuestro análisis, los resultados del backtest y
los textos de esta página se publican bajo licencia
CC BY 4.0:
úsalos, compártelos o analízalos libremente, citando la fuente,
Team Banzai (team-banzai.com). Los datos de terceros (el archivo
público de incidencias de la Apache Software Foundation) conservan las condiciones de
sus fuentes originales.
Hecho con TypeScript y PostgreSQL. Recuperación semántica sobre el histórico y modelos
de lenguaje para redactar el consejo, con doble juez automático independiente de
proveedores distintos y abstención obligatoria.
Sobre esta demo
Estudio retrospectivo con fines ilustrativos, sobre el archivo público de incidencias
de un proyecto de software de la Apache Software Foundation (sin afiliación). Los
tickets citados son históricos y están resueltos. Este análisis no evalúa al proyecto
ni a sus colaboradores, y no constituye recomendación técnica sobre el software
analizado.
¿Y en tu empresa?
Sirve igual para darle a un comercial recién llegado la respuesta que daría el veterano
ante una objeción, para ayudar a un técnico a diagnosticar una avería a partir de años
de intervenciones anteriores, o para orientar a quien atiende una consulta que ya se ha
resuelto cien veces, pero nunca por esa persona.
Si alguno de estos experimentos te recuerda a un problema tuyo, una cola de soporte donde cada respuesta se reinventa, la solución buena enterrada en tickets viejos, lo que ya se resolvió cien veces y se vuelve a resolver desde cero, escríbenos
y lo comentamos. Sin rollo: te decimos si se puede o no.