Dominio 3 — Entender los datos y la arquitectura de Copilot

Peso en el examen: 10-15%

¡Holi! 🌸 Este dominio es más cortito en peso, pero muy conceptual y "de esquema", y tiene una ventaja enorme: si te aprendes el viaje que hace tu prompt desde que lo escribes hasta que recibes la sugerencia, tienes prácticamente todas las preguntas ganadas. Es un dominio muy "mecánico" — se trata de entender un proceso paso a paso y en orden. Y para que ese orden no se te olvide jamás, vamos a usar una analogía que lo convierte en algo visual e imposible de confundir: un viaje en avión. ✈️

Antes de empezar, una idea que vertebra todo el dominio: Copilot no manda tu prompt directamente al modelo de IA. Entre tu teclado y el LLM hay toda una infraestructura de recogida de contexto, filtrado y seguridad — de ida y de vuelta. Entender esa infraestructura es de lo que va este dominio.

Antes de entrar al detalle técnico, quédate con esta imagen mental, porque es el andamiaje sobre el que colgaremos todo lo demás. Tu prompt es una viajera que va a coger un vuelo, y todo el flujo de datos de Copilot es su viaje de ida y vuelta:

1. Facturación → recoges tu equipaje (Copilot recopila el contexto de tu código).
2. Control de seguridad de salida → revisan que no lleves nada raro (el proxy filter + el filtro de toxicidad).
3. El vuelo → el avión te lleva a destino (el LLM genera la respuesta).
4. Aduana a la llegada → revisan lo que traes de vuelta (filtros de calidad, seguridad y código público).
5. Sales del aeropuerto → llegas a tu destino con tu maleta (la sugerencia aparece en tu editor).
6. Y si vuelves a viajar → repites todo el circuito (el feedback loop).

Fíjate en un detalle que el examen adora: hay controles a la ida (inbound) Y a la vuelta (outbound). Mucha gente solo recuerda los de entrada y falla las preguntas sobre el post-procesado. Con la imagen del aeropuerto — control de salida y aduana de llegada — no se te olvidará. Ahora desglosamos cada etapa. 🌸

La explicación en profundidad

Cuando escribes un prompt — ya sea un comentario en lenguaje natural o un mensaje en el chat —, arranca el procesamiento inbound, que tiene cuatro pasos bien definidos y en un orden concreto que el examen pregunta.

Paso 1 — Transmisión segura + recogida de contexto. Lo primero: tu prompt viaja siempre cifrado por HTTPS, garantizando confidencialidad en el tránsito. Y simultáneamente, Copilot hace su "facturación de equipaje": recopila todo el contexto que le ayudará a darte una buena sugerencia. Ese contexto incluye:

• El código inmediatamente anterior y posterior a tu cursor.
• El nombre y el tipo del archivo que estás editando (un .py le dice que es Python, un test_ en el nombre le sugiere que son tests…).
• El contenido de las pestañas abiertas adyacentes — por eso mantener abiertos los archivos relacionados mejora las sugerencias.
• La estructura del proyecto y las rutas de los archivos.
• Los lenguajes y frameworks en uso.

Aquí entra una técnica clave que cae con frecuencia: Fill-in-the-Middle (FIM). En lugar de mirar solo lo que has escrito antes del cursor, FIM considera también lo que hay después. Esto le da una comprensión mucho más rica de qué encaja en el hueco donde estás escribiendo.

Paso 2 — Proxy filter. El prompt, ya con su contexto, viaja a un servidor proxy alojado en un tenant de Azure propiedad de GitHub. Graba esto a fuego, porque es de lo más preguntado: el proxy no está en tu máquina, no está en OpenAI, no está en tu repo — está en Azure, y es de GitHub. Este proxy filtra el tráfico y, entre otras cosas, bloquea intentos de manipular el prompt (los llamados "prompt hacking" o "jailbreaks", donde alguien intenta engañar al sistema para que revele cómo funciona o para saltarse sus restricciones).

Paso 3 — Filtrado de toxicidad (toxicity filtering). Antes de que el prompt llegue al modelo, pasa por un filtro que detecta y bloquea discurso de odio, contenido inapropiado y datos personales (nombres, direcciones, identificaciones), protegiendo la privacidad.

Paso 4 — Generación con el LLM. Solo ahora, con el prompt limpio, filtrado y enriquecido con contexto, llega al modelo de lenguaje para que genere las sugerencias.

⚠️ Trampas típicas

• Colocar el proxy después de la generación → en el inbound el proxy va antes del LLM.
• Situar el proxy en tu máquina, en OpenAI o en tu repo → está en un tenant de Azure de GitHub.
• Entender FIM como "rellenar huecos en tu código" → es la técnica de preprocesado que usa contexto anterior y posterior.

📝 Mini-repaso

1. Ordena los cuatro pasos del proceso inbound.
2. ¿Dónde se aloja el proxy filter?
3. ¿Qué considera la técnica FIM que la distingue de un autocompletado normal?

La explicación en profundidad

El modelo ya ha generado una respuesta… pero esa respuesta no llega directa a tu editor. Igual que al volver de un viaje pasas por la aduana, la sugerencia atraviesa varios controles de salida antes de aparecer en tu pantalla.

Paso 5 — Post-procesado y validación. Aquí ocurren tres cosas:

• El filtro de toxicidad actúa de nuevo, ahora sobre el contenido generado (no solo sobre tu prompt de entrada). Tiene sentido: el modelo podría producir algo inapropiado aunque tu prompt fuera inofensivo.
• El proxy aplica una capa final de comprobación de calidad y seguridad, buscando bugs comunes y vulnerabilidades como XSS (cross-site scripting) o inyección SQL. Si detecta problemas graves, la sugerencia se trunca o se descarta.
• Matching public code (filtro de código público, opcional). Si el administrador (o tú, en planes individuales) lo tiene activado, este filtro bloquea las sugerencias de más de ~150 caracteres que coincidan estrechamente con código público existente en GitHub. Es opcional: no está activado por defecto.

Paso 6 — Entrega y feedback loop. Solo lo que ha superado todos los filtros llega a tu editor. Y a partir de ahí, Copilot inicia un bucle de retroalimentación: aprende de qué haces con la sugerencia — si la aceptas, la editas o la rechazas — para mejorar la experiencia.

Paso 7 — Repetición. El ciclo completo se repite con cada nuevo prompt.

El detalle del filtro de código público (cae seguro)

Este filtro merece atención porque genera muchas preguntas, y en el Dominio 6 lo veremos desde el ángulo de las salvaguardas. Por ahora, los tres datos clave: actúa en el outbound (a la vuelta, no a la ida), es opcional (lo activa el admin o el usuario individual), y su umbral es de ~150 caracteres. Compara la sugerencia (más unos ~150 caracteres de contexto alrededor) contra un índice de repositorios públicos de GitHub. Solo indexa repos públicos (no los privados ni el código de fuera de GitHub), y las coincidencias ocurren en menos del 1% de las sugerencias.

⚠️ Trampas típicas

• Decir que el filtro de código público está siempre activo → es opcional.
• Situarlo en el inbound → actúa en el outbound, después de que el LLM genere.
• Olvidar que el filtro de toxicidad actúa dos veces (entrada y salida).

🎯 Lo que cae en los tests reales

• Qué marca el filtro de toxicidad: hate speech o lenguaje discriminatorio y contenido sexual o explícito. ❌ No marca código con errores lógicos ni opiniones fuertes en comentarios.
• Coincidencia exacta vs parecida: una sugerencia que coincide exactamente con unos 200 caracteres de un repo público la bloquean los filtros de duplication detection (umbral ≈150 caracteres). Las sugerencias parecidas pero no exactas las gobierna el ajuste de code referencing. Fíjate si el enunciado dice exact o similar.
• Copilot es multi-modelo: soporta varios modelos con capacidades y compromisos distintos, y la elección del modelo sí afecta a la latencia y a la calidad.
• Contexto de inferencia: tus prompts, el contenido del archivo actual y el código de alrededor. ❌ No ejecuta tu código, no usa plantillas guardadas y no "usa siempre todo el historial del repositorio".

📝 Mini-repaso

1. ¿Qué tres comprobaciones ocurren en el post-procesado?
2. ¿El filtro de código público actúa a la ida o a la vuelta? ¿Está siempre activo?
3. ¿Qué es el feedback loop?

La explicación en profundidad

Si juntamos la ida y la vuelta, tenemos el ciclo de vida completo de una sugerencia de código, que es literalmente uno de los objetivos del examen ("visualizar el ciclo de vida"):

Si te acuerdas del aeropuerto ✈️, ya te sabes el ciclo entero de memoria: facturas el equipaje (contexto), pasas el control de seguridad de salida (proxy + toxicidad), vuelas (LLM), pasas la aduana de llegada (calidad + seguridad + código público), sales con tu maleta (entrega) y, si vuelves a viajar, repites el circuito (feedback loop). 🎀

Este esquema mental te permite responder cualquier pregunta de ordenación o de "en qué punto ocurre X" sin dudar.

La explicación en profundidad

Más allá del recorrido técnico, el examen quiere que entiendas qué garantías de privacidad rodean a tus datos. Este bloque conecta directamente con el Dominio 6 y con las preocupaciones legítimas de cualquier empresa que adopta Copilot.

Los puntos esenciales:

• Todo el tránsito va cifrado (HTTPS). Tus datos nunca viajan en claro.
• El proxy es un servicio que preserva la privacidad (privacy-preserving proxy), alojado en el tenant de Azure de GitHub.
• Los prompts y las respuestas no se persisten al pasar por el proxy: no se almacena el contenido del chat.
• Los prompts y completions NO se usan para entrenar los modelos base de Copilot en los planes de negocio. Este punto es importantísimo y muy preguntado: tu código privado no acaba entrenando al modelo. Y ojo con los matices absolutos de las trampas: no es "solo si desactivas la telemetría", ni "solo en Enterprise" — sencillamente no se usa para entrenar.
• La telemetría que sí se recoge son señales de actividad y uso de las funciones (cuántas completions, actividad del chat, uso de agentes) con fines de reporting — no el contenido de tu código fuente.
• El historial del chat aporta contexto para respuestas más relevantes, pero no entrena al modelo ni se comparte con otros usuarios.

⚠️ Trampa típica

• "Tu código privado se usa para entrenar el modelo (salvo que desactives la telemetría)" → falso. No se usa para entrenar, sin peros.
• Confundir telemetría (señales de uso) con contenido del código (que no se recoge).

📝 Mini-repaso

1. ¿Se usan tus prompts y completions para entrenar los modelos de Copilot?
2. ¿Qué es exactamente la telemetría que sí se recoge?
3. ¿El historial del chat entrena al modelo?

La explicación en profundidad

Cerramos el dominio entendiendo por qué Copilot tiene límites — no basta con saber que los tiene, el examen quiere que comprendas la causa. Y la causa está en la naturaleza misma de un LLM.

Las limitaciones concretas que confirma la documentación y que caen en el examen:

• Alucinaciones: puede inventar APIs, funciones o elementos de esquema que no existen, sobre todo cuando el contexto es limitado. Suena real, pero no lo es.
• Sin conocimiento en tiempo real de archivos remotos: Copilot solo "ve" lo que tienes abierto en el editor (o la conexión/contexto activo). No navega por carpetas ni repositorios por su cuenta a menos que se los abras. Por eso una pregunta trampa que diga "Copilot conoce todos los archivos de tu repo aunque no los abras" es falsa.
• No mantiene tipos ni estado en conversaciones largas: según se alarga un chat, los resultados pueden derivar (perder relevancia y coherencia). Esto conecta con el consejo del Dominio 4 de resumir o resetear el historial.
• Requiere conexión a internet: necesita el servicio en la nube de Copilot; no hay modo offline.
• Ventana de contexto limitada: no procesa todo tu repositorio de golpe, solo el contexto que se le pasa.
• Corte de conocimiento temporal: puede desconocer librerías o APIs publicadas después de su entrenamiento.
• Rinde mejor en inglés y hereda sesgos de sus datos.

⚠️ Trampa típica

• "Copilot conoce siempre la última versión de cualquier librería" → falso (corte de conocimiento).
• "Copilot entiende todo tu repositorio completo aunque no abras los archivos" → falso (solo ve lo abierto; ventana de contexto limitada).
• "Copilot funciona offline" → falso (necesita el servicio en la nube).

📝 Mini-repaso

1. ¿Qué es una alucinación en un LLM?
2. ¿Puede Copilot leer archivos de tu repo que no tienes abiertos?
3. ¿Funciona Copilot sin conexión a internet?

• Flujo del prompt (inbound/outbound) — Microsoft Learn
• Datos de Copilot y LLMs
• GitHub Copilot Trust Center (manejo y retención de datos)