Lo que ocurre realmente entre que dejas un manuscrito en Bethaniel y recibes uno con anotaciones: las pasadas, el orden en que se ejecutan y por qué está cada una.
Seis párrafos, luego el detalle.
Las etapas se ejecutan en orden, y el orden transmite información: la fragmentación no puede ocurrir antes de la detección de capítulos, y el revisor no puede puntuar una corrección que aún no se ha propuesto.
DOCX, EPUB, PDF, Markdown o texto plano. El DOCX entra a través de mammoth; EPUB y PDF tienen sus propios lectores. El lector de PDF reconstruye párrafos, énfasis y títulos a partir de dónde se sitúan físicamente los glifos en la página, y rechaza de plano los documentos escaneados en lugar de fingir que los lee.
Internamente todo se convierte en Markdown. Ese único formato interno es lo que permite que una corrección encontrada en el capítulo 12 se escriba de vuelta en el DOCX original con su formato intacto.
Se detectan los títulos y el manuscrito se divide en unidades editables. Las secciones de menos de cincuenta palabras (portadas, un título suelto, una dedicatoria) se pliegan dentro del capítulo al que pertenecen en lugar de convertirse en su propio «capítulo» de una línea, que es lo que hace que la lista de progreso de un trabajo se lea como el índice de un libro y no como la salida de un analizador.
Los marcadores de cambio de escena se reconocen y normalizan al mismo tiempo, de modo que un manuscrito que usa *** en un sitio y # en otro sale uniforme.
Cada capítulo se divide en fragmentos de unas 2.500 palabras, cortando solo en los límites de párrafo, con el último párrafo de un fragmento repetido al inicio del siguiente. El solapamiento es lo que evita que una corrección en la costura de un fragmento se haga sin contexto. Los límites de capítulo ponen el solapamiento a cero: el final del capítulo 4 no es contexto para el inicio del capítulo 5.
Antes de que el modelo vea nada, los comprobadores basados en reglas recorren el fragmento. Son rápidos, son iguales cada vez y nunca inventan una palabra. Lo que encuentran entra en el conjunto de correcciones y en el prompt del modelo como pistas, porque un corrector ortográfico sabe que una palabra está mal con mucha más fiabilidad de la que sabe cuál debería haber sido, y el modelo que lee la frase es mejor en la segunda parte.
El fragmento, las pistas deterministas, tu guía de estilo si la has aportado y los ajustes que has elegido se ensamblan en un prompt. El modelo devuelve las correcciones propuestas como pares original/corregido, no como un fragmento reescrito, de modo que un cambio siempre puede localizarse, mostrarse y rechazarse individualmente.
A su lado, una pasada aparte lee el mismo fragmento buscando una sola cosa: una palabra que se ha caído de una frase. Se describe más abajo, en Palabras que faltan.
Un segundo prompt devuelve cada corrección propuesta al modelo en el papel de un segundo lector escéptico: ¿es esto realmente un error, y es esta realmente la corrección? Cada una recibe una puntuación de confianza de 1 a 5. Todo lo que queda por debajo del umbral se marca en lugar de descartarse, de modo que una sugerencia correcta que al revisor no le gustó queda señalada para tu atención en vez de desaparecer. Un hallazgo del diccionario o del servidor gramatical nunca se anula de este modo: un diccionario no es una opinión que un modelo pueda votar en contra.
El revisor se ejecuta en paralelo con el editor del siguiente fragmento, así que la pasada adicional cuesta mucho menos tiempo real del que parece.
Cada corrección superviviente tiene que pasar un conjunto de guardas mecánicas antes de poder tocar el texto. Se describen abajo; la forma más corta de decirlo es que a una corrección no se le permite empeorar el manuscrito de una manera que un corrector humano jamás haría.
Obtienes una diferencia en línea a nivel de palabra, corrección por corrección, con el motivo adjunto y la puntuación de confianza visible. Aceptar, descartar o aceptar todo. Exporta a Markdown, DOCX o EPUB, y en el caso de una importación DOCX, de vuelta al documento original con sus propios estilos, en lugar de a uno generado de cero.
La decisión de diseño central es que los comprobadores basados en reglas y los basados en modelo se mantienen como fuentes separadas, se ejecutan sobre el mismo texto y se fusionan después. Ninguno puede hacer el trabajo del otro.
a/an, palabras duplicadas, apóstrofos ausentes, «PIN number»Nunca alucinan. Tampoco pueden saber que their debería haber sido there, porque ambas son palabras reales.
Lee la frase. También propondrá de vez en cuando algo equivocado con total confianza, y por eso nada de lo que dice se aplica sin revisar.
Aprobación previa entre fuentes. Cuando un comprobador determinista y el modelo producen de forma independiente la misma corrección, se aplica automáticamente sin necesitar la bendición del revisor. Una regla y un modelo de lenguaje se equivocan de maneras completamente distintas, así que su coincidencia es una señal mucho más fuerte que la confianza de cualquiera de los dos por separado.
Hunspell auténtico, compilado a WebAssembly, que lee sin modificar los pares de diccionario estándar .aff/.dic. Marca cada palabra del fragmento que no está en el diccionario, sin límite por fragmento, protegiendo a la vez los nombres de tu hoja de estilo y las palabras que se comportan como nombres propios.
Usar el motor real en lugar de una reimplementación es lo que hace que funcionen los idiomas que forman compuestos. El danés y el alemán construyen palabras nuevas uniendo otras (rådhusarkivet, Werkstattfenster), y una novela en cualquiera de los dos está llena de compuestos que no aparecen en ningún diccionario. Hunspell los compone a partir de sus partes. Un comprobador sin esa maquinaria lee cada uno de ellos como una falta de ortografía, lo que en la práctica significa que el autor desactiva el corrector.
Palabras que el diccionario nunca puede atrapar, porque ambas grafías son reales: their/there, en danés nogen/nogle, en alemán das/dass, en español si/sí. Bethaniel lleva un conjunto seleccionado por idioma e inyecta los relevantes en el prompt del modelo, pero solo cuando ambos miembros de un par aparecen realmente cerca el uno del otro en el fragmento. Una regla que saltara en cada aparición de their inundaría el manuscrito; una pista que solo salta donde la confusión es posible no cuesta casi nada.
«They expect us to look each other in the same place.» Cada palabra que está ahí está bien escrita, así que ningún diccionario ve el for que se cayó, y un autor lo lee de largo, porque la mente pone la palabra. Pedir al modelo editor que también las buscara no funcionó: no encontró más y empezó a pasar por alto errores que antes detectaba.
Así que es una pasada propia, en tres pasos. El modelo lee el fragmento en tandas pequeñas buscando palabras omitidas y nada más. Después, una regla se queda solo con una sugerencia que inserta exactamente una palabra pequeña —una preposición, un artículo, un pronombre, un auxiliar— entre dos palabras que ya están, lo que descarta casi todo lo que propone el modelo. Por último, al modelo se le muestra la frase dos veces, tal como está y con la palabra, y se le pregunta cuál es gramatical. Lo que sobrevive se te muestra como cualquier otro hallazgo y cuenta como bloqueante en la lectura final. Funciona en los cinco idiomas; la página de rendimiento dice lo bien que lo hace, por idioma y por motor.
Un servidor LanguageTool local, que se ejecuta sin conexión en tu ordenador, en su nivel de reglas más estricto, picky. Los instaladores publicados incluyen tanto LanguageTool como un entorno Java compatible, así que no hay nada que instalar; si falta, se limita a no hacer nada en lugar de hacer fallar el trabajo.
Una lista corta de reglas de LanguageTool está desactivada de forma permanente, cada una con la medición que la puso ahí. El listón es deliberadamente severo (cero errores reales encontrados, al menos uno inventado) porque una corrección de LanguageTool se salta al revisor, así que nada aguas abajo frena una regla que se dispara mal. Una regla española, que reescribía cada comilla recta como una angular, se disparaba 248 veces en el corpus de prueba y no había acertado ni una sola vez con un error real.
Comprobaciones deterministas solo para inglés: a frente a an, apóstrofos ausentes en contracciones, palabras duplicadas, acrónimos redundantes y espaciado entre frases. Los demás idiomas se saltan esta pasada por completo antes que recibir reglas inglesas.
La reparación de comillas es determinista, porque la diferencia entre una comilla de apertura y una de cierre es algo que un modelo pasa por alto y una regla nunca. Las comillas son enteramente suyas, y por eso al servidor gramatical no se le permite tocarlas. La normalización de la variante (de ortografía británica a americana o al revés) funciona igual, una vez has indicado en cuál está el manuscrito.
Algunas cosas que parecen errores son decisiones. La regla de Bethaniel es que, donde una convención está realmente en disputa, el autor la indica y solo entonces se aplica, porque un comprobador que adivina se equivoca la mitad de las veces y hace ruido en cualquier caso.
| Idioma | La elección | Por defecto |
|---|---|---|
| Inglés | Coma de Oxford | Activada |
| Inglés | Coma tras una frase introductoria | Desactivada: «Finally she turned» se deja tal como está escrito |
| Inglés | Ortografía británica o americana | Americana |
| Danés | Grammatisk komma o nyt komma | Grammatisk |
| Español | Convenciones de coma de la RAE | Aplicadas |
El caso danés es el más claro. El danés tiene dos sistemas de coma en competencia, ambos sancionados por el Retskrivningsordbogen y mutuamente contradictorios: el grammatisk komma pone una coma antes de cada subordinada; el nyt komma, en general, no. Imponer cualquiera de los dos sin preguntar es un error para la mitad de los manuscritos daneses. La detección de comas en danés se dejó deliberadamente débil hasta que existió este interruptor.
Entre el revisor y tu pantalla hay un conjunto de guardas mecánicas. Existen porque cada una describe algo que ocurrió realmente durante el desarrollo, y cada una es ahora una prueba que falla si vuelve a ocurrir.
.,, nada de punto doble. Y cuando el modelo reescribe la última frase de un párrafo y pierde su punto final (cosa que hace), el punto se restituye sin desechar la corrección legítima que venía con él.Las guardas se aplican a todas las fuentes, incluidas las deterministas. Una corrección basada en reglas no tiene privilegios solo porque la haya producido una regla.
La corrección de texto es una de cuatro pasadas. Comparten toda la canalización de arriba (fragmentación, revisión, guardas, ruta de exportación) y difieren en el prompt y en lo que producen.
| Pasada | Qué hace |
|---|---|
| Corrección de texto | Ortografía, puntuación, gramática, mayúsculas, palabras duplicadas. La capa mecánica. |
| Edición de estilo | Estilo, ritmo, redacción, redundancia. Sugerencias más que correcciones: aquí no existe una coma objetivamente ausente. |
| Traducción | El texto completo a cualquier idioma de destino, luego una pasada de pulido en ese idioma y después una revisión de fluidez párrafo a párrafo que vuelve a pulir todo lo puntuado como confuso. Solo en la nube: véase más abajo. |
| Análisis | Catálogo de personajes, catálogo de lugares y cronología, fusionados a lo largo de todos los capítulos, más un resumen en prosa generado automáticamente y un texto promocional. |
Seleccionar corrección de texto y edición de estilo a la vez las fusiona en una sola pasada por capítulo en lugar de recorrer el manuscrito dos veces. Seleccionar varias pasadas de análisis hace lo mismo.
La canalización es idéntica en los cuatro casos. Lo único que cambia es dónde ocurre la inferencia y si el texto sale de tu ordenador.
| Modelo | Se ejecuta en | El texto se queda en local |
|---|---|---|
| Local Betty — Qwen3.5 4B | Tu ordenador · ~3 GB, 8 GB de RAM libres | Sí |
| Custom Betty | Tu ordenador · cualquier GGUF que aportes | Sí |
| External Betty | Tu propia clave de API, el proveedor que elijas | No |
| Betty in the Cloud — alojada, UE | El servicio alojado de Bethaniel, pagado por trabajo | No |
Local Betty es la opción por defecto, y la aplicación es plenamente utilizable sin haber tocado nunca la red. Antes de descargarla, el botón de ejecutar dice cuánto debería tardar una novela en el equipo que tiene delante. Las opciones en la nube existen para máquinas que no pueden ejecutar un modelo 4B a una velocidad útil: se eligen por trabajo, y las condiciones dicen claramente qué pasa con el texto.
La única excepción es la traducción. El modelo local se midió en ella y no era lo bastante bueno: una traducción floja es fluida, segura y errónea, y un autor que no lee ambos idiomas no puede verlo. Por eso la aplicación rechaza un trabajo de traducción en un modelo local. La traducción solo se ejecuta en Betty en la nube, con un modelo mucho más grande que el de las pasadas de corrección, o con tu propia clave.
Antes ofrecía de dos a cuatro agentes editores por fragmento, y varios revisores, con la teoría de que se podían agrupar opiniones independientes. Se midieron, y no había opiniones independientes que agrupar.
Las correcciones se decodifican de forma voraz: se pide al modelo la única respuesta más probable en lugar de una muestra, porque encontrar un error es una pregunta con una respuesta correcta y no una creativa. Haz la misma pregunta de ese modo dos veces y obtendrás la misma respuesta dos veces. Cada agente adicional releía el mismo fragmento con el mismo prompt y devolvía una lista idéntica byte a byte, que el paso de fusión volvía a plegar en una sola.
Medido en cuatro idiomas y tres modelos: un editor y dos produjeron una salida idéntica en todos los casos (las mismas correcciones, los mismos fallos, las mismas marcas sobre texto limpio), y uno era entre un 15 y un 20 % más rápido. Así que las opciones se eliminaron en lugar de dejarlas como un ajuste que te cuesta tiempo y energía a cambio de nada. Se mantiene la única excepción: cuando aportas una hoja de estilo, un segundo agente se ejecuta con un prompt realmente distinto, y ese sí puede discrepar.
Creo que Betty es buena. También creo que es importante dejar claro dónde ayuda, dónde no, y a qué te apuntas.
Betty es una herramienta, no una profesional. Es una ayuda para escribir, no una correctora, revisora o asesora legal cualificada. Sus sugerencias son puntos de partida, no veredictos. La decisión final sobre cada frase es tuya.
A veces se equivocará. El lenguaje depende del contexto de maneras realmente difíciles. De vez en cuando Betty marcará algo que estaba bien, pasará por alto algo que no lo estaba, o sugerirá un cambio que empeora las cosas. Trata sus resultados como una segunda opinión, no como una edición definitiva.
Local por defecto; la nube solo si la pides. A su aire, Betty procesa el texto exclusivamente en tu propio hardware y no se transmite nada. La excepción es un trabajo en la nube — opcional en cada trabajo y pagado antes de ejecutarse: el pasaje que se edita viaja cifrado a infraestructura europea que no lo escribe en ninguna base de datos ni en ningún registro. En cualquier caso conservas todos los derechos sobre tu manuscrito y sobre el resultado editado, y nada de lo que escribes se usa para entrenar ningún modelo. Las condiciones de la nube dicen con claridad qué pasa con el texto.
Ejecutarla en local necesita un hardware capaz. El modelo local necesita 8 GB de RAM libres mientras trabaja —en la práctica, un ordenador con 12 GB o más, o con 8 GB y todos los demás programas cerrados— y unos 3 GB de espacio libre en disco. La velocidad depende de la parte gráfica: un Mac con Apple Silicon o una tarjeta NVIDIA con 8 GB de memoria de vídeo corrige una novela en unas tres horas o menos, mientras que solo con el procesador tarda casi un día entero. Tiempos previstos según el equipo. Hace trabajo computacional de verdad: no hay versión ligera. La opción en la nube es justo para esas máquinas: el modelo corre en el centro de datos y en la tuya no tiene que caber nada más que la propia aplicación.
Plataformas compatibles. Betty está disponible actualmente para macOS 12 o posterior, Windows 10 (64 bits) o posterior y sistemas Linux con glibc 2.31 o más reciente. Otras plataformas no son compatibles por ahora.
Betty es gratis, y pretende seguir siéndolo. Ejecutar Betty en tu propio ordenador no tiene límite de uso, ni suscripción ni periodo de prueba, y ese es el producto. Hay una opción de pago, un servicio en la nube que se cobra por trabajo, para máquinas que no pueden ejecutar un modelo en local: 5 € por cada 100.000 palabras para una corrección o una lectura final, 12 € para una traducción. Nunca es necesaria para usar Betty. Si algo de la versión gratuita cambia, se anunciará aquí antes de que entre en vigor, con antelación suficiente para tomar una decisión meditada.
Sin garantías. Betty se ofrece tal cual. No garantizo la exactitud, la idoneidad para ningún propósito concreto ni la disponibilidad ininterrumpida. Úsala bajo tu propio criterio.
Toda afirmación de esta página que lleva una cifra sale de una prueba de referencia que cualquiera con el repositorio puede volver a ejecutar. Textos emparejados (un texto limpio y el mismo texto con un centenar de errores plantados en posiciones de carácter conocidas) pasan por la canalización real, y lo que vuelve se puntúa contra lo que se plantó.
Los textos con errores están construidos, no anotados: un generador planta cada error según un plan por idioma y rechaza cualquier edición que no produzca exactamente un tramo del tipo previsto, de modo que la verdad de referencia no puede desviarse del texto. Las pasadas se puntúan de forma distinta porque fallan de forma distinta: exhaustividad y precisión contra los errores plantados para la corrección de texto, y chrF contra traducciones humanas de referencia, más comprobaciones de proporción de longitud y de palabras sin traducir, para la traducción.
Los resultados, por idioma, con los fallos desglosados según qué tipo de error se pasó por alto, están en la página de rendimiento.