El escritorio se quedó sin T9: por qué y cómo podrían arreglarlo los LLM

Los textos de trabajo los escribimos sobre todo en el ordenador: correos, documentación, tickets, código, comentarios en el código. Sin embargo, la autocorrección inteligente se quedó en el teléfono. Allí la palabra se arregla mientras se escribe, mientras que en el PC al usuario le esperan una línea ondulada roja y un menú contextual con el botón derecho del ratón.

La brecha se nota desde que los smartphones recibieron teclados táctiles, es decir, hace más de década y media. Un análisis reciente en Habr vuelve sobre la cuestión: por qué el escritorio no aprendió más y si se puede arreglar con LLM. A continuación repasamos las causas y lo que realmente cambian aquí los modelos de lenguaje.

La publicación original en RSS solo ofrece un adelanto, así que lo que sigue se apoya en la arquitectura de entrada de texto, de sobra conocida, y en el estado del mercado.

Por qué el teléfono tiene autocorrección y el PC no

En un smartphone, el teclado es una aplicación. Ve las coordenadas de cada toque, la probabilidad de pulsar las teclas vecinas y el contexto de la frase escrita. La autocorrección es allí una necesidad: el dedo es más grande que la tecla y sin ella no se puede escribir. El desarrollador del teclado controla toda la capa de entrada, por lo que puede sustituir palabras, cambiar las anteriores y aprender de los hábitos del propietario.

En el escritorio el panorama es el contrario. El teclado físico es más preciso, los errores suelen ser menos y no hay una necesidad acuciante. Además, el texto acaba en navegadores, IDE, mensajeros, terminales y suites ofimáticas, cada uno con su propio motor de texto. No existe un punto único donde interceptar la entrada y cambiar una palabra con limpieza. Hay que trabajar mediante API de accesibilidad o ganchos a nivel de sistema. Es frágil, distinto en cada SO y con frecuencia falla en los campos protegidos.

También está la cuestión de la confianza. Un programa que lee todo lo que se escribe se parece, por definición, a un keylogger. Para los datos de trabajo es un obstáculo serio: abogados y equipos de seguridad prohibirán de buen grado una herramienta así.

Qué cambian los modelos de lenguaje

La autocorrección clásica se basa en un diccionario y en estadística de n-gramas. Corrige bien los errores dentro de una palabra, pero entiende mal el contexto: no distingue «ложить» de «класть» (dos formas rusas) por el sentido de la frase y tropieza con la jerga profesional. Un modelo de lenguaje mira la oración completa y evalúa qué palabra encaja. Apple ya ha pasado la autocorrección de iOS a un modelo de tipo transformer, y en macOS han aparecido sugerencias integradas de continuación. Es decir, los grandes fabricantes están dispuestos a llevarlo al escritorio, aunque por ahora lo hacen con cautela y sobre todo para un conjunto limitado de idiomas.

El cambio principal tiene que ver con el tamaño. Modelos de unos pocos miles de millones de parámetros, por ejemplo de la clase Phi-3-mini con 3,8 mil millones, ya se ejecutan en un portátil sin la nube. Eso elimina parte del problema de privacidad: el texto no sale del equipo. Quedan la latencia y los recursos.

Las referencias para una herramienta así son estas:

• latencia de la sugerencia: del orden de 100 ms, o se queda por detrás de lo que se escribe;
• tamaño del modelo: de cientos de millones a varios miles de millones de parámetros, cuantizado;
• funcionamiento sin conexión, sin enviar texto a un servidor;
• soporte del ruso, con sus casos y su orden libre de palabras, donde los modelos débiles fallan más;
• configuración de excepciones para contraseñas, terminal y código.

Qué hacer en la práctica

Si necesitas corrección inteligente en el PC ya, hay tres caminos viables. Primero: usar la revisión ortográfica y de estilo del navegador y de las suites ofimáticas. No sustituye al T9, pero cubre parte de las tareas. Segundo: instalar una herramienta local basada en un modelo pequeño y probarla con tus propios textos, fijándote en la latencia y en cómo se comporta en el IDE y en la terminal. Tercero: si desarrollas este tipo de productos, empieza por escenarios acotados, como la corrección en una sola aplicación o en un solo campo, y solo después pasa al nivel del sistema.

Elijas lo que elijas, comprueba tres cosas. Dónde se procesa el texto: en local o en la nube. Qué aplicaciones no toca la herramienta. Y cómo se comporta en ruso, no solo en inglés. El T9 de escritorio sigue siendo un nicho, pero los obstáculos técnicos son claramente menores que hace unos años.