Dónde ayuda un modelo NLI en un asistente de reuniones: tres pruebas, dos rechazos

Charoiteai, desarrollador del asistente local de reuniones Charoite, contó dónde funciona un modelo NLI y dónde estorba. Lo probó en cinco lugares: quedaron dos.

En julio ejecutó la misma acta de reunión cuatro veces por el modelo de resumen automático y obtuvo 39 afirmaciones distintas, de las cuales 32 aparecieron en una sola ejecución. Quería una herramienta que señalara dónde se contradicen las ejecuciones. Eligió mDeBERTa-v3-base-xnli-multilingual-nli-2mil7: multilingüe, entrenado con 2,7 millones de pares, 1,1 GB en formato ONNX, carga en segundo y medio.

Primer lugar: repeticiones en el feed en vivo — funciona a diario

En una reunión larga, el modelo de resumen solo ve 800 caracteres de texto reciente, así que repite con otras palabras lo que ya se dijo. NLI detecta duplicados mediante lógica bidireccional: es un duplicado cuando A se deduce de B y B se deduce de A simultáneamente. Una aclaración (solo en una dirección: "presupuesto aprobado" se deduce de "presupuesto aprobado hasta fin de año", pero no al revés) permanece en el feed. Una contradicción no pasa en ninguna dirección.

El esquema es simple: una nueva afirmación se compara con las 16 anteriores mediante difflib con un umbral de 0,3 (deliberadamente bajo para no filtrar antes de tiempo). Los pares que pasan van al modelo en ambas direcciones. Si ambas probabilidades son ≥ 0,8, la afirmación se descarta como duplicado; de lo contrario, se mantiene. El umbral es 0,8 y no el 0,75 por defecto, porque una repetición molesta, pero perder un hecho nuevo es peor. Cada llamada tarda decenas de milisegundos, y la mayoría de los pares nunca llega al modelo gracias al prefiltro.

Este es el único lugar donde NLI funciona sin problemas desde hace tres meses consecutivos. No es perfecto: en una reunión del 29 de septiembre, el mismo tema volvió cinco veces en 8 minutos sin añadir nada nuevo. El mecanismo ya está anotado: es la próxima tarea.

Segundo lugar: contradicciones en actas — rechazado

Lo probó con el archivo: 14 reuniones, 51 puntos de acta, 1192 pares para analizar. De los 76 pares que pasaron el prefiltro, el modelo marcó 30 como contradicciones. Casi todas eran falsas. La causa es la longitud: el punto de acta promedio tiene 138 caracteres, el 69% supera los 120. Una frase como "Es necesario iniciar contacto directo con la persona responsable para aclarar los principios generales de conexión, sin pasar por las etapas intermedias de aprobación" son en realidad tres ideas en un solo párrafo. En cualquier par de párrafos así siempre habrá una palabra en común y algo que parezca un conflicto.

La solución es dos órdenes de magnitud más barata: las afirmaciones cortas (hasta 60 caracteres) con un objeto nombrado, junto con números y fechas, se verifican directamente contra la transcripción mediante búsqueda. En la misma ejecución, este tipo de verificación encontró una invención entre diez afirmaciones: un lanzamiento programado para el "17/08", cuando el 17 de agosto nunca se mencionó, ni en cifras ni con palabras.

Tercer lugar: revisión nocturna de núcleos — desactivada

Los núcleos son temas que duran más de una reunión. Cada núcleo tiene una esencia, una cronología, personas y decisiones. El problema: el mismo tema se llama de distintas formas. Un ejemplo del documento de arquitectura en el repositorio: configurar el acceso a la API y obtener el token son el mismo trabajo, pero dos núcleos con dos cronologías incompletas.

La revisión funcionaba en dos pasos: bge-m3 reunía candidatos (similitud coseno desde 0,55), luego NLI juzgaba su esencia en ambas direcciones con cuatro resultados posibles: duplicado (ambas direcciones por encima de 0,8 — candidato a fusión); posible duplicado (0,72–0,8 — marcado); anidamiento (una dirección por encima de 0,85, la otra por debajo de 0,5 — un tema estrecho dentro de uno amplio); frontera (ambas por encima de 0,45 — temas vecinos). Un núcleo con tres anidamientos se consideraba un hub y no se tocaba.

En agosto se veía bien: 284 núcleos activos, 40186 pares, 1806 pasaron el prefiltro, revisión completada en 6 minutos. Para octubre había más de 1000 núcleos. La revisión del 27 de septiembre chocó con el límite nocturno tras 3,5 horas y dejó 824 núcleos para las noches siguientes. Los dosieres (resúmenes por tema) no se compilaron en absoluto en ocho de doce noches.

Revisó diez pares aleatorios de alta confianza que la revisión estaba a punto de fusionar. Cero eran duplicados reales. Uno era discutible.

La confianza de los pares falsos: entre 0,93 y 1,00. La explicación: no todos los núcleos tienen una esencia propia. Si no la tienen, la revisión recurre a un estado genérico como "Discusión de requisitos y características".

Dos temas de trabajo distintos con el mismo estado genérico, y NLI dice: estas frases se deducen una de la otra. Sí, se deducen, porque es exactamente la misma frase. El modelo funcionó correctamente, pero es un error de datos, no del modelo.

Las marcas de posible duplicado se acumularon hasta 239 en el grafo, cero revisadas: nadie abrió la nota de servicio con las marcas.

El 5 de octubre lo desactivó con una sola línea en la configuración. Nunca activó la fusión automática, pero ahora está claro que habría unido temas de trabajo distintos; una sugerencia durante una reunión habría mostrado el estado de la tarea de otra persona. La copia de seguridad de fusión dura una semana y nadie la revisa: en la práctica, es irreversible.

Cuarto lugar: filtro antes del rayo — no ayudó

El botón ⚡ (respuesta rápida) se activa ante una pregunta recién formulada en la llamada. Un filtro estructural encuentra un candidato en el feed y un modelo local escribe la respuesta en segundos. Pero a veces el candidato no es realmente una pregunta: alguien repitió algo, pensó en voz alta o cortó una frase a medias. El modelo responde "no veo una pregunta" y se pierde tiempo.

Quería un juez más barato antes del modelo, sin ajuste fino: dos hipótesis afirmativas (las hipótesis con negación funcionan peor en el modelo): "El interlocutor hace una pregunta y espera una respuesta" y "El interlocutor repite, piensa en voz alta o corta una frase". Una cascada: si hay confianza, decide por sí mismo; si no, se lo pasa al modelo.

En modo sombra: el juez calculaba en paralelo sin decidir nada, solo registraba en el log. Cuatro reuniones, 117 intervenciones. El modelo respondió a 115, se negó en 2, es decir, el 1,7%, el techo de lo que el filtro podría ahorrar incluso en el mejor caso.

Pero NLI estaba lejos de ser perfecto. Precisión frente al estándar: 55,6%, casi una moneda al aire. Mala calibración: confiado notablemente más a menudo de lo que acertaba. Tiempo mediano de llamada: 99 ms. Comprobó distintos umbrales:

| Umbral | Filtrado | Vacías eliminadas | Preguntas perdidas | |--------|----------|---------------------|----------------------| | 0,60 | 31,6% | 1 de 2 | 31,3% | | 0,70 | 17,9% | 1 de 2 | 17,4% | | 0,80 | 9,4% | 0 | 9,6% | | 0,90 | 0 | 0 | 0 |

Con cualquier umbral que filtre algo, el sistema pierde preguntas reales decenas de veces más de lo que elimina vacías. Había escrito la regla de cierre una semana antes de la medición: si las vacías son menos del 15%, cerrar el tema. Salió 1,7%. El 6 de octubre desactivó la sombra.

Qué se rompió

Lo más desagradable fue un fallo silencioso. La primera vez: los modelos están en la raíz de datos, pero el código buscaba el modelo NLI junto a sí mismo, en la raíz de código. En el repositorio del propio desarrollador ambas raíces coinciden, así que el defecto era invisible. En una instalación donde los datos están separados, el modelo no estaba en esa ruta. La regla vigente era: si no hay modelo en disco, la deduplicación se desactiva. Sin error, sin advertencia, el feed simplemente volvía a repetirse. Lo notaron no por el feed, sino durante una revisión. Ocurrió dos veces. Ahora la ruta se calcula en el momento de la llamada.

La segunda vez fue en la revisión de núcleos, también dos veces consecutivas. El juez se cargaba pero no podía juzgar, y la revisión contaba la ejecución como completada: no encontraba pares, movía la marca hacia adelante, y los núcleos nuevos quedaban fuera de revisión por completo. Un cero en la revisión significaba "similar" en lugar de "nada que juzgar". Ahora un fallo del juez es una excepción, no un cero.