En resumen.
Hay dos maneras de darle una regla al modelo que redacta un borrador. Puedes escribirla en las instrucciones y confiar en que el modelo la siga. O el software revisa el borrador terminado y lo rechaza si incumple la regla.
En nuestro ejemplo más claro, la regla que solo se indicaba no se mantuvo. Durante unas dos semanas, las instrucciones le decían al modelo exactamente cómo despedirse. De los 178 borradores de ese periodo, 40 llevaban la despedida tal como se indicaba, 93 se apartaban de ella y 45 no tenían ninguna.
Por eso las reglas importantes son ahora controles que rechazan, y cada rechazo queda registrado con la regla que lo provocó. Este artículo muestra lo que detectaron esos controles. No demuestra que los mensajes mejoraran, y el ejemplo es una sola configuración, no una tasa general.
Una instrucción, dos semanas sin control.
Un espacio de trabajo puede fijar cómo terminan sus mensajes: las palabras de cierre y el nombre. Es la regla más sencilla que tenemos. No exige criterio, solo copiar.
Más o menos del 7 al 20 de septiembre, las instrucciones al modelo indicaban la despedida y nada comprobaba el resultado. Revisamos los borradores del propio modelo de ese periodo y comparamos su final con la despedida configurada.
Estas cifras tienen tres límites. Todos los borradores contados como «distintos» proceden de una sola configuración y se apartan de la misma forma, en un detalle pequeño. Comparamos borradores antiguos con la despedida tal como está configurada hoy. Y el inicio del periodo es la fecha en que se escribió la instrucción, no la fecha en que entró en funcionamiento. Así que esto muestra una configuración que se desvía. No es una tasa general de cuántas veces un modelo se salta una instrucción.[1]
La noche del 20 de septiembre, la despedida pasó a ser un control. Un borrador sin la despedida correcta se rechaza. Desde entonces el control ha rechazado 46 veces: 44 porque faltaba la despedida y dos porque era distinta.
Estos 46 rechazos no se pueden comparar con los 178 borradores. Un rechazo es un suceso, y un mismo borrador puede rechazarse varias veces. Los dos recuentos miden cosas distintas en periodos distintos.
Lo que se rechazó.
SYNC redacta por dos vías. En la primera se registraron 527 rechazos entre el 7 y el 29 de septiembre. La tabla los ordena según el motivo del rechazo.
| Qué rechazó el control | Rechazos | Primera vez |
|---|---|---|
| El texto no tiene saltos de párrafo | 86 | 11 sept |
| El mensaje cita su fuente o dice que alguien ha mirado | 65 | 7 sept |
| Una cifra sobre el remitente que no figura en su propia descripción | 63 | 9 sept |
| La pregunta final pide una hora o un formato que las normas de redacción no permiten | 60 | 7 sept |
| Falta la despedida | 44 | 20 sept |
| Un seguimiento repite el mensaje anterior tras su apertura | 42 | 9 sept |
| Frases que repiten un email ya enviado | 39 | 7 sept |
| El borrador volvió con una parte ausente | 25 | 11 sept |
| Una fecha que la investigación sobre la cuenta no respalda | 24 | 11 sept |
| Una primera palabra que las normas de redacción prohíben | 22 | 9 sept |
| La respuesta no se podía leer como borrador | 20 | 7 sept |
| El mismo argumento que en mensajes recientes a otras cuentas | 11 | 20 sept |
| El mensaje sermonea al lector | 8 | 9 sept |
| Una expresión que las normas de redacción prohíben | 7 | 21 sept |
| El mensaje alterna el trato formal y el informal | 5 | 25 sept |
| La despedida difiere de la configurada | 2 | 23 sept |
| Otros | 4 | varias |
Esto no es una clasificación de los errores del modelo. Los controles se añadieron semana a semana, como muestra la última columna. Un control que existe desde hace tres semanas ha tenido más tiempo para rechazar que uno que existe desde hace cuatro días. Un error para el que no hay control no aparece en absoluto.
La segunda vía registra cada intento de redacción desde el 21 de agosto. Muestra adónde va el esfuerzo.
| Segunda vía de redacción | Cantidad |
|---|---|
| Intentos de redactar un borrador | 221 |
| Borradores aceptados | 54 |
| Intentos que no pasaron un control | 133 |
| De ellos, frenados primero por el control de formato | 122 |
| De ellos, frenados primero por un control de estilo | 11 |
| Intentos en los que falló la conexión | 34 |
Según nuestra propia división, salen unos cuatro intentos por cada borrador aceptado. La mayoría de los fallos no tienen nada que ver con el contenido. En 122 de los 133 controles fallidos, el modelo no devolvió su respuesta en el formato pedido, así que no había ningún borrador que juzgar.
Qué dicen otros estudios.
No encontramos ningún estudio sobre esta cuestión aplicado al email comercial. La investigación más cercana se pregunta si un modelo al que se le pide respaldar sus afirmaciones con fuentes lo hace de verdad. Dos estudios lo midieron.
«incluso los mejores modelos carecen de un respaldo completo de citas el 50 % de las veces»
Ese resultado corresponde a un solo conjunto de preguntas de respuesta larga. Un segundo estudio examinó cuatro buscadores públicos que responden con frases completas y fuentes. Su conclusión, de media: «apenas el 51,5 % de las frases generadas está plenamente respaldado por citas».[3]
Darle al modelo el material de origen sí ayuda. Un estudio halló que los modelos que buscan pasajes antes de escribir producen un lenguaje más fiel a los hechos que los que no lo hacen.[4] Otro halló que buscar pasajes reduce de forma notable los datos inventados en la conversación.[5] Ambos registran una reducción. Ninguno dice que el problema haya desaparecido.
Qué cambiamos en el producto.
- 01Una regla importante es un control sobre el borrador terminado. Si el borrador la incumple, el software lo rechaza.
- 02Cada rechazo queda registrado con la regla que lo provocó. Ese registro es la fuente de las tablas de este artículo.
- 03El 20 de septiembre, la despedida pasó de las instrucciones a un control.
Lo que juega en contra.
No podemos demostrar que los controles mejoraran los mensajes. Contamos rechazos, y un rechazo solo indica que un patrón coincidió. Un borrador rechazado podía estar bien a ojos de una persona, y uno que pasó puede seguir siendo flojo.
Un control solo puede comprobar lo que un software puede comprobar. Los saltos de párrafo, una despedida o una palabra prohibida son fáciles. Que un mensaje sea relevante para quien lo lee, no. Las cualidades más importantes de un mensaje siguen siendo meras indicaciones, y según nuestro propio hallazgo las indicaciones se desvían.
Los controles cuestan intentos. En la segunda vía, los 221 intentos pertenecen a 98 ejecuciones, y 44 de ellas nunca produjeron un borrador aceptado. Cada intento rechazado cuesta tiempo y dinero, y un conjunto estricto de controles puede dejar una cuenta sin mensaje.
Nuestro ejemplo más claro es limitado. Las cifras de la despedida proceden de muy pocas configuraciones, y todos los borradores distintos, de una sola. El inicio del periodo es aproximado: es la fecha en que se añadió la instrucción, no una fecha registrada con cada borrador. Todos nuestros recuentos proceden de tres espacios de trabajo y de unas pocas semanas.
Los estudios externos tratan sobre responder preguntas y sobre la conversación. Ninguno estudió el email comercial, y ninguno comparó una regla indicada con una regla comprobada. Los usamos como la evidencia más cercana, no como prueba.
Contamos los rechazos en el registro de cada borrador y de lo que pasó con él: 527 en la primera vía, del 7 al 29 de septiembre, y 133 controles fallidos en la segunda, del 21 de agosto al 29 de septiembre. Presentamos todos los espacios de trabajo juntos. No damos una tasa de rechazo, porque los rechazos son sucesos y un borrador puede rechazarse más de una vez.
Las categorías de la primera tabla se obtienen buscando patrones en el texto del motivo registrado con cada rechazo. Para la despedida revisamos los borradores del propio modelo en la primera vía, en espacios de trabajo que tienen una despedida configurada. Quedan fuera los borradores de la segunda vía, los escritos después de que empezara el control y los anteriores al 7 de septiembre, porque el inicio del periodo es aproximado y no podemos saber con qué instrucciones se escribieron.
Las cifras valen para el momento en que se tomaron. Volvemos a medir el día de la publicación.
- [1]iSyncSO. Decisiones sobre borradores, rechazos por regla e intentos de redacción, hasta el 29 de septiembre de 2026. Medido el 29 de septiembre de 2026.medición propiaun número reducido de espacios de trabajo
- [2]Gao, T., Yen, H., Yu, J. & Chen, D. (2023). Enabling large language models to generate text with citations. arXiv:2305.14627.solo el resumenleído en arXiv; respuesta a preguntas, no email comercial
- [3]Liu, N. F., Zhang, T. & Liang, P. (2023). Evaluating verifiability in generative search engines. arXiv:2304.09848.solo el resumenleído en arXiv; cuatro buscadores, no email comercial
- [4]Lewis, P. et al. (2020). Retrieval-augmented generation for knowledge-intensive NLP tasks. NeurIPS 2020. arXiv:2005.11401.solo el resumenleído en arXiv
- [5]Shuster, K., Poff, S., Chen, M., Kiela, D. & Weston, J. (2021). Retrieval augmentation reduces hallucination in conversation. arXiv:2104.07567.solo el resumenleído en arXiv