.jpg)
En la primera parte explicamos cómo entrenamos nuestro modelo NES, incluyendo tokens especiales, afinado LoRA sobre Gemini Flash Lite y el uso de un LLM juez para evaluar resultados. Pero la experiencia final va mucho más allá de crear un buen modelo. Para que NES se sienta consciente de la intención del desarrollador dentro del editor, hace falta darle al modelo el contexto adecuado en el momento preciso. En esta segunda parte describimos el sistema en tiempo real que gestiona, ordena y transmite el contexto de edición, es decir cómo Pochi administra el contexto en vivo para entender la intención y predecir el siguiente cambio significativo.
Por qué importa la gestión del contexto El bloque entre que el usuario empieza a teclear y el momento en que llamamos al modelo con un prompt ordenado es crítico. En esa fase intermedia el sistema recoge y prepara todo el contexto relevante que el LLM necesita antes de una petición. Si simplemente enviáramos todo el archivo en cada pulsación, la latencia aumentaría, las predicciones serían inestables y el número de llamadas al modelo podría superar las 20 por segundo, haciendo la experiencia inutilizable. En lugar de eso, NES recibe tres tipos de contexto: <|editable_region|> o región editable del archivo, <|edit_history|> o historial de ediciones recientes, y <|additional_context|> con extractos opcionales de otros archivos que ayuden a entender el archivo actual. Cada uno de estos depende de filtrado, segmentación y sincronización inteligentes que ocurren en milisegundos durante la escritura normal.
1. Contexto del archivo y la región editable La primera pregunta es dónde está editando el usuario ahora. Para responderla se recogen tres datos desde la API de VS Code: el texto completo del archivo, la ruta del archivo y la posición del cursor. Con esto calculamos la llamada región editable, normalmente una ventana pequeña alrededor del cursor de aproximadamente 10 líneas. Diez líneas es un buen equilibrio porque la siguiente edición suele ocurrir muy cerca del cursor, manteniendo la latencia mínima y capturando la estructura necesaria para que el modelo entienda el contexto inmediato. Además, limitar la región evita que modelos sobre-ansiosos reescriban partes del archivo que el usuario no estaba tocando.
2. Historial de ediciones: seguir la intención en el tiempo Saber dónde se edita es importante, pero también es vital comprender cómo evoluciona el código a lo largo del tiempo. Registrar cada evento de cambio a nivel de pulsación provocaría ruido: por ejemplo cambiar un tipo de string a email puede generar unas seis notificaciones que no representan pasos de edición significativos. Si enviáramos cada pulsación, el modelo consideraría cada una como una intención distinta y dispararía demasiadas solicitudes con predicciones inconsistentes. Para evitarlo reconstruimos pasos de edición reales mediante una agrupación interna de eventos de cambio.
Cómo agrupamos eventos en pasos significativos: en lugar de usar los eventos crudos del listener, los reducimos a unidades comparables a pasos de deshacer-rehacer. Muchos editores registran esos pasos a escala de palabra; nosotros los hacemos a una escala ligeramente mayor para la predicción de edición. Al iniciar el seguimiento con la posición del cursor, creamos una lista de pasos de edición donde cada paso acumula varios eventos de cambio de texto. Hemos comprobado que cinco pasos es el punto óptimo para construir un prompt: más añade ruido, menos pierde intención. Para cada evento comprobamos si es adyacente al anterior; si lo es pertenece al mismo paso, si no es un nuevo paso. Por ejemplo, si primero se actualiza una línea y luego se añade una función validateEmail en otra parte, tendremos dos pasos de edición en el seguimiento. NES recibe estos pasos envueltos en el token <|edit_history|> para aprender la evolución del código.
Casos especiales: ruido por git checkout. Un caso límite es cuando el usuario ejecuta git checkout para cambiar de rama, lo que provoca cambios masivos de archivo que no reflejan intención del usuario. Si tratásemos esos cambios como pasos de edición, el modelo podría creer que el usuario reescribió medio repositorio. Para evitarlo monitorizamos el estado git, reiniciamos el historial de edición cuando cambia el estado git por checkout pull o stash y reanudamos el seguimiento tras unos segundos.
3. Contexto adicional: traer el resto del proyecto El código raramente vive aislado. Si se edita una llamada a función el modelo puede necesitar la definición; si se cambia un tipo puede necesitar la declaración del tipo. Para dotar a NES de una comprensión consciente del proyecto extraemos fragmentos relevantes usando el servidor de lenguaje instalado por el usuario. Utilizamos dos APIs de VS Code y LSP: vscode.provideDocumentRangeSemanticTokens para escanear la región editable por tipos de token y localizar tokens de interés como funciones o interfaces, y luego vscode.executeDefinitionProvider para obtener la ubicación de la definición en otro archivo, similar a hacer Ctrl o Cmd clic sobre una función. Extraemos ese fragmento de definición e inyectamos el contenido en el token <|additional_context|>.
Limitación y buenas prácticas: algunas funciones o tipos pueden ser enormes y el LSP a veces devuelve cuerpos enteros de clase. Para controlar esto limitamos la extracción semántica a un máximo de 2000 caracteres por fragmento. En escenarios con soporte LSP pobre, como texto plano, no añadimos snippets relacionados y el prompt seguirá conteniendo prefijo, sufijo y registros de edición.
Ensamblando todo Cada petición a NES contiene los tokens <|editable_region|>, <|edit_history|> y <|additional_context|> cuidadosamente construidos exactamente como en el entrenamiento. Esta simetría entre entrenamiento y tiempo de ejecución hace que NES sea más fiable que enfoques de autocompletado nativos. Además, la cancelación inmediata de predicciones obsoletas —tirar todo lo que no sea la última intención del usuario— es clave para que Pochi y NES se sientan rápidos y precisos. En la próxima entrega hablaremos sobre Request Management, el sistema que evita que el modelo acierte sobre un contexto que ya no existe, gestionando peticiones en vuelo, actualizaciones de cursor y cancelaciones de respuestas caducas.
Sobre Q2BSTUDIO En Q2BSTUDIO somos especialistas en desarrollo de software y aplicaciones a medida, inteligencia artificial aplicada a empresas y ciberseguridad. Diseñamos e implementamos soluciones de software a medida y aplicaciones a medida integrando servicios cloud como AWS y Azure, y ofrecemos servicios de inteligencia de negocio y power bi para mejorar la toma de decisiones. Si buscas proyectos de inteligencia artificial o agentes IA para automatizar flujos de trabajo y potenciar tus productos consulta nuestra oferta de IA para empresas y descubre cómo abordamos IA industrial y modelos adaptados a tus necesidades. Para proyectos de producto o aplicaciones complejas trabajamos en desarrollo a medida; conoce nuestros servicios de desarrollo de aplicaciones y software a medida. También proporcionamos servicios de ciberseguridad y pentesting, servicios cloud aws y azure, integración de power bi y consultoría de inteligencia de negocio, siempre con enfoques prácticos y orientados a valor.
Si te interesa mejorar la experiencia de edición con modelos de código o explorar cómo la IA puede integrarse en tus productos, contacta con Q2BSTUDIO para diseñar una solución a medida que combine agentes IA, automatización de procesos y seguridad desde la arquitectura hasta la entrega.
