Cómo JetBrains construye búsqueda semántica para código: RAG en producción

Por qué los agentes de código necesitan búsqueda semántica y no solo `grep`

Cuando un agente de IA busca dónde se refrescan los tokens de sesión, no sirve de mucho que la palabra «refresh» aparezca en el código: los lenguajes usan nombres abstractos y la semántica se pierde entre flush, drain, rotate o expire. Por eso JetBrains publicó el 4 de octubre de 2026 en su blog de IA la primera entrega de un developer diary sobre Air Context, su motor de RAG (Retrieval-Augmented Generation) para búsqueda semántica de código, integrado en la nueva familia JetBrains Air anunciada el 22 de septiembre de 2026.

La idea de fondo es directa: indexar repositorios enormes no por palabras clave, sino por significado, para que un agente pueda pedir el fragmento de código relevante en lenguaje natural y recibirlo citado. El propio artículo de JetBrains lo define: si el embedding captura la semántica y la consulta es texto libre, «creamos una interfaz que juega con las fortalezas del agente».

Chunking por AST, no por número de líneas

La mayoría de tutoriales de RAG recomiendan partir el texto en ventanas de N tokens. Para código eso es catastrófico: junto a una función acabarían pegados un import y un if sin relación, y el embedding resultante no significa nada.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

JetBrains aplica chunking con conciencia de estructura (structure-aware chunking). Usa los parsers que su plataforma Code Engine ha pulido durante 26 años para descomponer cada archivo en un stream de nodos sintácticos: comentarios, modificadores, clases, métodos, decoradores, anotaciones. A partir de ahí, el algoritmo decide el tamaño de cada chunk en función del tipo de nodo y de su tamaño:

Si un nodo cabe bajo el umbral, se queda entero. Si no, se subdivide solo lo necesario.
Documentación, anotaciones y modificadores se pegan a la declaración a la que pertenecen.
Decoradores de Python viajan junto a la función, KDoc junto a la declaración de Kotlin.
Anotaciones sin valor semántico (@NotNull, @Override) se eliminan para no contaminar el embedding.

El resultado se normaliza: se quitan espacios, líneas en blanco y se normaliza la indentación, conservando la relativa para que el bloque siga siendo código válido. El artículo reconoce que la idea tiene similitudes con cAST, publicado por Zhang et al. en 2025, pero codificando más semántica por lenguaje.

Air Context soporta parsing consciente de estructura para nueve lenguajes: Kotlin, Java, Python, JavaScript, TypeScript, C#, PHP, Go y Rust. Para el resto, cae a un fallback de partición por líneas, para garantizar que cualquier archivo es indexable.

Vectorización: 4.096 dimensiones, pero de un bit cada una

Un repositorio grande produce millones de chunks, y cada vector en coma flotante de 32 bits ocupa unos 16 KB. Multiplicado por millones de fragmentos, el índice se dispara a decenas de gigabytes antes de empezar a hablar de metadatos.

JetBrains toma dos palancas que pueden combinarse: recortar dimensiones o recortar precisión por dimensión. Su conclusión tras medir es contraintuitiva: las dimensiones importan más que la precisión. Su analogía es potente: cada dimensión es una pequeña pregunta que el modelo aprendió a hacer sobre el texto («¿toca red?», «¿es código de test?», «¿maneja errores?»).

Con un presupuesto de 512 bytes por vector, hay dos opciones: 128 dimensiones a 32 bits, o 4.096 dimensiones a 1 bit. La segunda recupera mucho mejor. Un cuestionario largo marcado con checks le gana a uno corto rellenado con seis decimales. Por eso Air Context reduce cada componente a su signo: ≥ 0 se convierte en 1, < 0 en 0. Los vectores pasan a ocupar 32 veces menos y la métrica deja de ser coseno (necesita magnitudes) para ser distancia de Hamming, que se calcula con un XOR palabra a palabra y se cuenta en instrucciones de CPU.

El coste que sí aceptaron

La cuantización binaria pierde algunos puntos de recall frente al vector original y, sobre todo, comprime el rango de similitud. Vectores no relacionados pueden coincidir en cerca de la mitad de los bits por azar, y los muy relacionados en dos tercios. Todos los scores caen en una banda estrecha. El ranking sigue funcionando, pero los umbrales de relevancia absoluta se rompen. Cuando un caso de uso necesita decir «esto es relevante o no» en lugar de «ordénalo de más a menos», mantienen vectores en coma flotante de 16 bits y pagan más almacenamiento.

Embedding del path: truncar por arriba y por abajo, no por el medio

JetBrains añade al embedding, junto al chunk, la ruta relativa del archivo, porque aporta contexto que el código solo no da. El problema es que en monorepos la ruta puede ser brutal: en el monorepo de IntelliJ IDEA, el archivo mediano vive a nueve directorios de profundidad, con paths de 91 caracteres de media, y cerca de 10.000 archivos superan los 150 caracteres; el más largo, 218.

La regla que aplican es mantener los dos extremos y podar el medio:

El prefijo largo indica el módulo en el que estás.
El sufijo (directorio padre + nombre de archivo) indica qué hace el archivo.
La parte intermedia repite la jerarquía de paquetes, que el compilador necesita pero la búsqueda no.

El texto se recorta con un cap, los segmentos sobrantes se eliden con …, y si padre + nombre aún no caben, se conserva solo el nombre. La misma forma abreviada se usa cuando el usuario acota la búsqueda a un subdirectorio, de forma que el vector de la consulta aterriza en la misma región del espacio que los chunks indexados.

Privacidad por diseño, sin sacrificar calidad

Air Context asume que el código fuente suele ser el core de la propiedad intelectual del cliente. Por eso la arquitectura hace dos cosas poco habituales:

No almacena el contenido del código. Cada chunk guarda una referencia de clúster, tipo de elemento, ruta, offsets de inicio y fin y una referencia al vector. Lo que devuelve una búsqueda son coordenadas, no el fragmento: el snippet se reconstruye en la máquina del usuario, desde su propio checkout, usando esos offsets. El servidor solo sabe que algo relevante vive entre los bytes 4.102 y 4.890 de una ruta.
No envía datos a entrenar nada. Todos los embeddings los genera un modelo de pesos abiertos corriendo en GPUs operadas por JetBrains. Ningún request sale a OpenAI, Google ni a otros proveedores. Según el propio blog, evaluaron candidatos abiertos frente a las APIs hospedadas de los principales proveedores y los suyos ganaron en sus benchmarks de recuperación sobre código.

La compañía enmarca Air Context como una pieza más dentro de JetBrains Air, el sistema abierto para desarrollo agentic presentado el 22 de septiembre de 2026. Air Context aporta la indexación semántica; Air Gateway lleva agentes de terminal como Claude Code o Codex al IDE; y Air Governance añade políticas, auditoría y control de gasto para que las organizaciones puedan desplegar agentes sin perder visibilidad.

Lecciones que cualquier founder puede aplicar a su propio RAG

Más allá de JetBrains, el recorrido deja principios transferibles a cualquier pipeline RAG sobre código o documentación técnica:

El chunking es producto, no un parámetro. Partir por número de líneas o tokens es la opción rápida, pero destruye semántica. Si indexas código, usa el AST; si indexas documentos, respeta títulos, secciones y tablas.
Embedding asimétrico: instruye la consulta, no el documento. Air Context entrena una asimetría deliberada entre la pregunta en lenguaje natural y el chunk de código, envolviendo la query con una instrucción tipo «dada esta búsqueda, encuentra el código que la responde». El documento entra crudo. Conserva ese mismo formato en inferencia.
Privacidad es ventaja competitiva. Procesar embeddings y storage en infraestructura propia evita fugas y, según JetBrains, no les costó calidad. Para startups que manejan datos sensibles de clientes, este es un eje de venta real.
Métricas de almacenamiento ≠ métricas de relevancia. Recortar dimensiones o precisión cambia la métrica que puedes usar. Bits piden Hamming; coma flotante pide coseno. Decidas la métrica, decides el formato.

Qué significa esto para tu startup

El campo de la búsqueda semántica para código está madurando rápido. Mientras las herramientas tradicionales de búsqueda de código (Sourcegraph, GitHub Code Search, ripgrep) son el estándar de facto, la generación de agentes que necesitan encontrar funciones, símbolos o definiciones específicas en repositorios cada vez más grandes está empujando a proveedores como JetBrains a construir índices semánticos especializados. El sector RAG en general ya adoptó el patrón de retrieval híbrido: un artículo reciente de InfoQ sobre retrieval híbrido para RAG destaca que los sistemas en producción combinan BM25 y búsqueda vectorial con Reciprocal Rank Fusion (RRF) y, opcionalmente, un reranker de cross-encoder, precisamente porque los embeddings solos fallan al distinguir identificadores exactos como códigos de error o versiones. Un desarrollador que trabaje sobre código tiene una distribución de consultas dominada por ese tercer caso híbrido.

Dos acciones concretas que puedes implementar esta semana

Audita cómo troceas tu código antes de embeberlo. Si tu RAG parte por número de líneas, prueba un parser de AST (tree-sitter sirve para más de 40 lenguajes) y mide recall con un LLM-as-judge. En menos de un día puedes detectar si tus chunks están mezclando imports con funciones o cortando docstrings por la mitad.
Mide el coste por byte de tu índice, no por embedding. El equipo de Air Context demuestra que con vectores de 4.096 dimensiones cuantizados a 1 bit, un índice de millones de chunks cabe en pocas decenas de GB. Si pagas por Pinecone, Weaviate o Qdrant, prueba matrices binarias + Hamming para tus datos fríos y reserva coma flotante solo para los casos donde necesites umbrales absolutos de relevancia.