8. Ingeniería del VLM: percepción semántica y decisiones de implementación

El capítulo 5 documenta la arquitectura de la consulta asíncrona del lazo lento (cuándo se solicita, cómo se integra al grafo, qué hace el sistema con la respuesta). El capítulo 6 documenta por qué hace falta un lazo lento (los puntos ciegos del estimador de flujo). Este capítulo documenta las decisiones de ingeniería del VLM, que el lazo lento admite como fuente alternativa y que usa el planificador de ruta: selección del modelo bajo restricciones de hardware, salida estructurada, rol del modelo como perceptor semántico, ingeniería del prompt y gestión de la latencia.

Rol del VLM. Con la configuración por defecto el VLM no interviene en el vuelo. Medido contra etiquetas de referencia, no distingue sectores volables de bloqueados ni rumbos abiertos de cerrados (cap. 11, §11.0). La capa estratégica y el barrido usan la profundidad estimada (cap. 6, §6.14), y el VLM trabaja en la planificación de ruta previa al vuelo (cap. 4, §4.3.1), la única tarea en la que aporta una señal medible. Lo que sigue describe la ingeniería del VLM, compartida por el planificador de ruta y por las fuentes alternativas del lazo lento, STRATEGIC_SOURCE = vlm y DEADLOCK_STRATEGY = deep_vlm.

8.1 Selección del modelo: restricciones de hardware como parámetro de diseño

La selección del modelo de lenguaje no es un proceso de benchmark abstracto sino un proceso de diseño con restricciones duras. El sistema corre en una RTX 5060 con 8 GB de VRAM compartidos con una simulación de Unreal Engine 5.5. AirSim sobre UE5.5 consume, en condiciones de vuelo activo, entre 4.5 y 6 GB de VRAM (Turco et al., 2024). El presupuesto efectivo disponible para la inferencia del modelo es de 2 a 3.5 GB de VRAM, incluyendo la KV cache del historial de prompt.

Esta restricción excluye inmediatamente a los modelos de referencia del estado del arte (GPT-4o, Claude 3.5, Gemini 1.5 — todos en la nube o con hardware dedicado de 24–80 GB) y orienta la búsqueda hacia modelos multimodales compactos cuantizados (Small Vision-Language Models, VLM), del orden de 1.5 a 7 mil millones de parámetros, ejecutados localmente (LM Studio, Ollama o vLLM).

8.1.1 El requisito de visión directa

Una distinción de diseño previa a la selección del modelo es si la consulta al modelo debe usar un modelo textual puro (recibe solo telemetría y resúmenes de percepción serializados) o un VLM multimodal (recibe además el fotograma de la cámara). El sistema adopta un VLM multimodal por razones que no son de conveniencia sino de cobertura funcional:

• Puntos ciegos del flujo óptico (§6.1, §6.12): cuando el estimador de flujo carece de evidencia (hover, giro puro, baja textura), el ObstacleField entregado al modelo es esencialmente vacío. Un modelo textual no puede razonar sobre la escena sin ese resumen; un VLM puede observar directamente el fotograma y evaluar el contexto visual.
• Semántica que el flujo no codifica: la distinción entre "árbol vs. edificio", "sombra vs. obstáculo sólido", o "calle con objetos vs. calle vacía" no está presente en el campo de divergencia. El VLM puede discriminar escenas semánticamente similares en percepción pero distintas en consecuencias de navegación.
• Geometría que el flujo no representa: las superficies horizontales a la altura de vuelo (tablero de una autopista elevada, cornisas, balcones) no producen expansión en el sector frontal; el fotograma sí las muestra. Es el obstáculo sobre el que el dron puede quedar apoyado e inmovilizado (cap. 9, §9.8.7).

8.1.2 Modelo adoptado y candidatos evaluados

El modelo adoptado es LFM2.5-VL-1.6B (Liquid AI; cuantización Q4_K_M, formato GGUF, 731 MB más el codificador visual), servido por Ollama en la misma estación y la misma GPU que la simulación y el grafo de control, con un contexto limitado a 8192 tokens. En Ollama es el tag local lfm2.5-vl-1.6b:q4km-ctx8k, creado desde hf.co/LiquidAI/LFM2.5-VL-1.6B-GGUF:Q4_K_M con num_ctx = 8192, y es el valor de LOCAL_LLM_MODEL_NAME y ROUTE_LLM_MODEL_NAME en config/.env (Anexo 6). Corre en la GPU de la simulación porque un VLM a bordo comparte el cómputo con el resto del sistema de vuelo, y esa es la condición representativa del dron real. Con 8192 tokens de contexto el modelo ocupa ~1.6 GB de VRAM medidos (con el contexto por defecto de 128 k, 3.1 GB, casi todo caché de atención); la consulta más pesada del sistema, un barrido de cuatro imágenes, usa ~800 tokens de entrada. La variante Extract del mismo modelo, ajustada para extracción, no se usa: completa el esquema JSON sin mirar la imagen (la misma grilla en las 43 consultas de un piloto). Combina un núcleo de lenguaje de 1.2 B de parámetros con arquitectura híbrida de convoluciones (decodificación rápida) y un codificador visual SigLIP2 de 400 M que representa cada imagen con 64–256 tokens. Frente a Qwen2.5-VL-3B-Instruct, el otro candidato con visión que cabe en la VRAM disponible, gana por latencia: Qwen tarda ~10–12 s por consulta con imagen (§8.6) y no discrimina mejor (cap. 9, §9.8.3). En los benchmarks públicos de comprensión visual ambos están en el mismo rango; ninguno mide la tarea de vuelo, que la decide el banco de prueba (cap. 11, §11.0). Se usa la versión GGUF y no la conversión MLX porque esta última devuelve una respuesta vacía cuando la consulta pide a la vez salida JSON restringida y logprobs. LFM2.5-VL-1.6B también es el modelo del planificador de ruta previo al vuelo (cap. 4, §4.3.1); Qwen2.5-VL-3B es el segundo modelo del banco de prueba (§10.13.4). Los modelos candidatos (documentados en informe/anexos/A1-EXPLORACION-SLM-GGUF.md) son:

Modelo	Tamaño (cuant.)	VRAM aprox.	Descartado por
Phi-4-mini-Instruct	~2.5 GB	~2–3 GB	Sin capacidad de visión nativa
Qwen3-4B-Instruct	~3 GB	~2.5–3.5 GB	Sin soporte visual en la rama 3B
SmolLM3-3B	~2 GB	~1.8 GB	Sin soporte visual; razonamiento débil
LFM2.5-VL-1.6B (Q4_K_M, GGUF)	0.73 GB + codificador visual	~1.6 GB (contexto 8 k)	Adoptado
Qwen2.5-VL-3B-Instruct (Q4_K_M)	~2 GB	~2.0 GB	~10–12 s por consulta con imagen, sin mejor discriminación (§8.1.2)
Qwen2.5-VL-7B-Instruct	~4.5 GB	~4–5 GB	VRAM insuficiente con UE5.5 activo

El criterio de selección es: (a) soporte de visión nativa, (b) memoria < 2.5 GB cuantizado, (c) soporte de response_format: json_schema en el backend de inferencia, (d) latencia de inferencia < 2 s en el hardware disponible para prompts de ~500 tokens con dos imágenes. Es un criterio de diseño; las latencias medidas se documentan en §8.6 (el barrido de cuatro imágenes lo supera).

8.1.3 Posicionamiento respecto al estado del arte

La arquitectura de lazo cerrado estado→VLM→macro-acción→ejecución no es, hacia 2025–2026, una contribución conceptualmente novedosa: es un patrón estandarizado en investigación y prototipos de UAVs controlados por modelos de lenguaje (véase la discusión en informe/anexos/A1-EXPLORACION-SLM-GGUF.md). Hwang et al. (2024) en EMMA y Saxena et al. (2025) en UAV-VLN son trabajos representativos del patrón. El aporte de esta tesis no está en la novedad de la arquitectura general, sino en la ingeniería de su interfaz con la percepción monocular (cap. 6) y en la caracterización sistemática de sus modos de falla (cap. 9).

8.2 Salida estructurada: decodificación restringida y parser

Sin restricciones sobre la salida, la causa más frecuente de fallo de la consulta al VLM no es una decisión incorrecta, sino una respuesta JSON malformada que rompe el parser. La salida se asegura en dos capas.

8.2.1 Decodificación restringida (json_schema)

La respuesta se solicita con response_format={"type": "json_schema", "json_schema": {...}}, disponible en LM Studio y en el backend OpenAI-compatible de Ollama. Durante la generación, el motor enmascara los logits de los tokens que producirían JSON inválido para el esquema, de modo que el modelo solo muestrea tokens válidos. El mecanismo —reformular la gramática del esquema como una máquina de estados finitos que restringe el conjunto de tokens admisibles en cada paso— es el que formalizan Willard y Louf (2023), base de la decodificación guiada que exponen hoy backends como llama.cpp; Raspanti et al. (2025) y Geng et al. (2025) evalúan empíricamente su impacto sobre la fiabilidad de la salida (desarrollo formal en el Anexo 4). Con la decodificación activa, el adherence_rate medido en escenarios de validación pasa de ~73 % (solo prompt) a ~98 %.

Hay dos esquemas, uno por modo de consulta (§5.10.5), y ninguno contiene un campo de acción: el modelo describe, el código traduce.

Esquema estratégico (RESPONSE_JSON_SCHEMA_STRATEGIC, vlm_strategic.py): una entrada por sector de la grilla de 3×3 del fotograma con valor free o blocked (enum cerrado); los nueve sectores son obligatorios. El parser los traduce a los valores internos libre y bloqueado, que son los que usan la sub-meta, los registros y el banco de prueba.

{
  "type": "object",
  "properties": {
    "cells": {
      "type": "object",
      "properties": {"A1": {"enum": ["free", "blocked"]}, "B1": {...}, ..., "C3": {...}},
      "required": ["A1", "B1", "C1", "A2", "B2", "C2", "A3", "B3", "C3"],
      "additionalProperties": false
    }
  },
  "required": ["cells"],
  "additionalProperties": false
}

Esquema panorámico (RESPONSE_JSON_SCHEMA_PANORAMA, deep_scan.py): un array views de objetos {img, view, free}: número de imagen, lo que hay delante a la altura del dron (enum de seis valores: open, facade, wall, vegetation, inside, unclear) y si se puede volar recto 15 m. El parser los traduce a los valores internos (libre, fachada, muro, vegetacion, interior, indeterminado; transitable). El esquema no pide certeza ni un indicador de imagen degradada: el modelo los rellena con valores fijos (el mismo 0.95, 0.92, 0.89, 0.86 en tres de cuatro barridos de un piloto; degradada: true en todas las respuestas) y ninguno decide nada. Una entrada free: true cuya vista no es open se contradice a sí misma y no cuenta como transitable (cap. 5, §5.12). Las imágenes se identifican por número y no por ángulo: el rumbo real de cada imagen lo conoce el código, no el modelo (§8.3.3).

8.2.2 Parser como red de seguridad

La garantía de json_schema depende de que el backend la soporte. Si la llamada con esquema falla, vlm_client._query_slm_impl() reintenta en modo libre; en ambos casos _extract_json_object() elimina cercos de markdown y extrae el primer objeto {...} del texto, y el parser del modo (parse_strategic o parse_panorama_description) lo valida: una respuesta estratégica con algún sector ausente o con un valor fuera del enum se rechaza completa, y una respuesta panorámica sin array views también. Una respuesta rechazada no se sustituye por una decisión determinista: la capa estratégica simplemente no propone sub-meta en ese ciclo (motivo no_parseable), y un barrido sin respuesta válida cae al escape vertical de §5.3.4 como cualquier otra falla del modelo.

8.3 Rol del VLM: percepción semántica anclada al mundo

El VLM no elige macro-acciones: describe lo que ve, y la capa de navegación convierte esa descripción en geometría. Lo que se le pregunta está elegido para que la respuesta siga siendo válida cuando llega.

8.3.1 Por qué esta pregunta

Una interfaz aparentemente más simple —pedir al modelo que describa tres sectores relativos al cuerpo (frente, izquierda, derecha)— tiene dos problemas, medidos en corridas de diagnóstico con esa interfaz (cap. 9, §9.8):

1. Latencia. Una respuesta con imagen tarda varios ciclos del lazo (cuatro con el modelo local; 5.3 s de mediana, ~26 ciclos, en un servidor compartido). El «frente» de la respuesta ya no es el frente del dron.
2. Contenido informativo. En 52 de 53 respuestas sectoriales (excluida una corrida en vegetación) el modelo declaró el frente transitable, incluso cuando la profundidad de referencia del simulador, consultada a posteriori, marcaba una superficie a 0.1–1 m. La respuesta es casi constante.

El diseño responde al primero anclando la respuesta a la pose del fotograma (§8.3.2) y, al segundo, con más granularidad (una grilla de 3×3, con la meta marcada en la imagen) y un prompt sin ejemplos de valores concretos que un modelo pequeño pueda copiar (§8.5.1). El banco de prueba responde si eso alcanza: no alcanza. Con LFM2.5-VL-1.6B la grilla queda en 53 % de exactitud balanceada (AUC 0.53), con las filas de arriba y de abajo «libres» en todas las muestras y la del medio dependiente de la posición del sector más que de la escena (cap. 11, §11.0).

8.3.2 Capa estratégica: grilla de 3×3 con dirección absoluta

Un recorte cuadrado del centro del fotograma frontal —se cortan los dos costados del ancho— se divide en una grilla de 3×3 por tercios —la grilla de composición fotográfica—: columnas A, B, C (izquierda a derecha) y filas 1, 2, 3 (arriba, a la altura del dron, abajo). Se marca en la imagen la dirección del destino, en azimut y elevación. Para cada sector el modelo dice si se puede volar en esa dirección al menos 15 m.

Una partición en columnas solo describe el eje horizontal. La grilla agrega el vertical: permite que la respuesta diga que un obstáculo a la altura del dron se pasa por arriba (fila 1 libre, fila 2 bloqueada) y que una superficie horizontal se ve en la fila del medio, sin pedir al modelo un concepto abstracto como «estructura debajo». Una pregunta de ese tipo («¿hay una estructura horizontal cercana?») recibe true en 5 de 6 consultas de diagnóstico, con imágenes muy distintas (cap. 9, §9.8.9).

La traducción (decide_subgoal, detalle en §5.10.3) usa la pose del fotograma: la dirección absoluta del sector es el yaw del ancla más el azimut del centro del sector, con la elevación del centro del sector. La sub-meta se fija desde la posición del ancla, a no más de 15 m y nunca más lejos que el waypoint real, con la misma función que usa el barrido. El recorte cuadrado deja los sectores laterales y los verticales a la misma distancia angular del centro (±24°), de modo que la preferencia entre un rodeo por el costado y uno por arriba no la decide la forma del cuadro: a igual distancia gana la fila del medio. La igualdad se toma con un margen de 10° (VLM_SUBGOAL_TIE_DEG): con empate exacto, una meta medio grado por debajo del dron haría ganar siempre a la fila de abajo, y el dron podría descender hasta apoyarse en el tablero de una autopista elevada (cap. 11, §11.0). Así, la geometría que el modelo describió se transporta al mundo sin depender de hacia dónde mira el dron cuando la respuesta llega. Si el sector de la meta está libre, la capa no agrega nada y descarta cualquier desvío pendiente: la respuesta más frecuente esperable («el camino directo está libre») no genera maniobras.

8.3.3 Barrido: imágenes numeradas, rumbos medidos

En el barrido de resolución de atasco (§5.12), el modelo recibe cuatro imágenes numeradas y describe cada una (img, view, free). El código asigna a cada imagen el yaw medido en el ciclo en que se capturó y elige, entre las transitables, la de rumbo absoluto más cercano al rumbo absoluto hacia el waypoint real. Las entradas se asignan por número de imagen (o por orden si falta), y las entradas que el modelo inventa de más se descartan.

El diseño evita un error de marco de referencia documentado en el capítulo 9 (§9.8.1): si las imágenes se etiquetan con su rumbo absoluto y se pide al modelo un ángulo relativo, el modelo copia la etiqueta y el código la interpreta como relativa, de modo que «la dirección hacia la meta está libre» termina ejecutándose como una evasión hacia el lado contrario.

8.3.4 Vocabulario de macro-acciones

El vocabulario del sistema es fijo (VALID_ACTIONS, action_map.py): MANTENER_RUMBO, EVADIR_IZQUIERDA, EVADIR_DERECHA, GANAR_ALTURA, PERDER_ALTURA, FRENAR, GIRAR_90 y RETROCEDER. El modelo no elige ninguna. Las descripciones del VLM producen, a través del código, MANTENER_RUMBO hacia una sub-meta, GANAR_ALTURA o PERDER_ALTURA (barrido sin rumbos transitables); el resto las emite el lazo rápido (evasión, GIRAR_90) o la FSM. RETROCEDER está definido pero ningún comportamiento del brazo slm lo emite (cap. 5, §5.3.4).

8.4 action_to_command: la frontera entre decisión y cinemática

Cada macro-acción se traduce a un comando cinemático en action_to_command() (src/agents/action_map.py), función compartida por el lazo rápido, el barrido y la FSM (tabla completa en cap. 5, §5.14). Valores relevantes: evasión lateral con yaw_rate ±15°/s y target_yaw redondeado a la cuadrícula de 90°, vx de 1.2 m/s en la evasión agresiva del lazo rápido; GANAR_ALTURA a −1.5 m/s en el lugar; PERDER_ALTURA a +0.8 m/s con avance de 1.0 m/s; GIRAR_90 a ±20°/s sin traslación; RETROCEDER a −1.2 m/s con rumbo congelado.

Invariante de diseño. Centralizar la traducción impide que una misma macro-acción tenga cinemáticas distintas según quién la active. Si cada brazo tuviera su propia tabla de velocidades, divergirían sutilmente (por ejemplo, distinta velocidad vertical para GANAR_ALTURA) y producirían diferencias de trayectoria entre brazos que no provienen de la decisión.

8.5 Ingeniería del prompt

8.5.1 Principios

Los prompts siguen cinco reglas:

1. Solo hechos, ninguna sugerencia de acción. Un prompt que pide al modelo «describir sin decidir» y a la vez le sugiere qué maniobra priorizar es contradictorio (cap. 9, §9.8.3). Los prompts dan solo lo que el modelo no puede ver en la imagen (distancia al destino, sector de la meta, altura) y piden una descripción.
2. Sin ejemplos. El esquema JSON ya fija la forma de la respuesta, y un modelo pequeño copia los valores de cualquier ejemplo ("ok": true, "conf": 0.9) en sus respuestas (cap. 9, §9.8.3).
3. La geometría la aporta el código. El modelo nunca reporta ángulos ni posiciones: identifica sectores o imágenes por su etiqueta, y el código conoce su dirección.
4. Lo visual en la imagen, no en el texto. La meta se marca sobre el fotograma (marca roja «GOAL» en su dirección, dentro de la grilla) en lugar de describirse como «X grados a la derecha».
5. En inglés y breves. Los modelos de este tamaño se ajustan a instrucciones mayoritariamente en inglés, y cada token del prompt se procesa en cada consulta. Cada prompt de sistema tiene tres o cuatro oraciones: qué ve el modelo, qué debe responder con una definición operativa de una línea y «solo JSON». Los valores del esquema también están en inglés; el parser los traduce a los valores internos. Ningún prompt nombra objetos de un escenario en particular (cap. 10, §10.12.2).

8.5.2 Prompt de la capa estratégica

System prompt (SYSTEM_PROMPT_STRATEGIC), completo:

You see the front camera of a drone flying low in a city, split into a 3x3 grid: columns A B C (left to right), rows 1 2 3 (top, drone height, bottom). The red GOAL mark is the destination. For each cell: "free" if the drone can fly 15 m that way, "blocked" if a building, wall, tree, bridge or roof is closer than 15 m. Reply with JSON only.

User prompt (strategic_prompt): Goal WP_3: 34 m, in cell B2. Altitude 10 m. Si la meta está fuera del recorte: Goal WP_3: 34 m, outside the image, 97 deg to the left (GOAL mark on the edge). Altitude 10 m. Le sigue una única imagen de 384 px con la grilla y la marca de la meta dibujadas, rotulada [Front camera, 3x3 grid].

8.5.3 Prompt del barrido

System prompt (SYSTEM_PROMPT_DEEP_SCAN), completo:

You see numbered images from a drone flying low in a city; it turned in place and each image faces a different direction. For each image give: - view: what is ahead at drone height within 15 m: open (street, square, sky), facade, wall, vegetation, inside (dark or uniform, inside a building) or unclear. - free: true only if the drone can fly straight 15 m without hitting anything. Reply with JSON only.

User prompt (_build_panorama_prompt): 4 images. Altitude 10 m., seguido de hasta cinco imágenes de 256 px rotuladas [Image 1] … [Image N]. El prompt no da ángulos, meta ni duración del atasco: el modelo solo describe cada imagen, y el rumbo de cada una y la elección los resuelve el código (cap. 5, §5.12).

8.5.4 Parámetros de inferencia

temperature = 0.2; tope de 384 tokens en el modo estratégico (nueve valores de enum) y 512 en el barrido. El tope no fija la longitud de la respuesta —con decodificación restringida, la generación termina al cerrar el esquema—: solo corta una generación desbocada, y una respuesta cortada se reporta como falla (respuesta_truncada), nunca se interpreta. Las respuestas no tienen campos de texto libre: no hay razonamiento que generar, lo que acota la latencia de decodificación.

Los system prompts están en el código (vlm_strategic.py, deep_scan.py).

8.6 Gestión de latencia

El tiempo de inferencia del VLM es un orden de magnitud mayor que el período del lazo (200 ms). La consulta corre en el hilo de DeliberationService (§5.10.5) y nunca bloquea al grafo. Esta separación entre una capa de ejecución rápida que siempre responde y una capa de razonamiento lento desacoplada es la instancia concreta, con un VLM como capa deliberativa, del patrón de arquitecturas de tres capas (Gat, 1998).

Latencia observada. LFM2.5-VL-1.6B (Q4_K_M), en la misma GPU que la simulación:

Fuente	Condición	Latencia
Piloto con STRATEGIC_SOURCE = vlm (65 consultas, sin timeouts)	Capa estratégica, un fotograma de 384 px	mediana 0.77 s · p90 0.80 s · máx 2.8 s
Banco de prueba (cap. 11, §11.0)	Grilla 3×3, un fotograma	0.88 s
Banco de prueba	Barrido de cuatro imágenes de 256 px	2.6–3.1 s

No provienen de una medición controlada que aísle carga de GPU, tamaño de imagen y arranque en frío. Como referencia, el candidato Qwen2.5-VL-3B (§8.1.2) tarda 5.3 s de mediana con un fotograma (p95 12.9 s, 73 consultas) y 5.6 s con un barrido de dos imágenes en las corridas de diagnóstico del capítulo 9. La consecuencia de diseño es la misma para ambos: ninguna latencia cabe en el ciclo de 200 ms; en 0.8 s el dron avanza unos metros y gira, y en 5 s recorre ~10 m y puede girar más de 90°.

Consecuencia para el comportamiento del dron.

• Capa estratégica. El dron no se frena: el lazo rápido sigue volando y la respuesta, cuando llega, se traduce con la pose del fotograma (§5.10.3). Mantener el avance preserva además la traslación que el flujo óptico necesita.
• Barrido de resolución de atasco. El dron permanece en el lugar mientras espera, bajo el watchdog SLM_DEEP_WATCHDOG_MS (18 s en producción, muy por encima de la latencia medida del barrido y por debajo del corte HTTP de 20 s). Al expirar, cae al escape vertical.

Validez de las respuestas. La validez se controla geométricamente, no solo por edad: la respuesta se descarta si tiene más de 10 s, si cambió el waypoint o si el dron ya superó la sub-meta que produciría; dentro de esos límites, girar mientras el modelo piensa no invalida la respuesta, porque está anclada al fotograma.

8.7 Nombres de campo compactos

Cada token de la respuesta cuesta tiempo de decodificación: en un servidor que genera ~15 tokens/s, ~67 ms por token. El esquema panorámico usa tres campos cortos por imagen (img, view, free), sin certeza, sin indicador de imagen degradada y sin campo de razonamiento; con nombres descriptivos (relativo_deg, transitable, confianza) una respuesta de cuatro imágenes llega a ~80–95 tokens. El esquema estratégico lleva la idea al extremo: nueve valores de enum y ningún texto libre. Los parsers aceptan también los nombres largos y normalizan a los nombres internos.

8.8 Nota: LoRA como alternativa explorada y no adoptada

El fine-tuning ligero vía LoRA (Low-Rank Adaptation) es una vía posible de especialización del modelo para la tarea de este sistema (Anexo 3). El argumento a favor es que un conjunto de pares (imagen, respuesta correcta) derivados de las corridas del sistema podría reducir la frecuencia de respuestas erróneas sin reentrenar el modelo base.

No se implementa por dos razones:

1. Cobertura de datos insuficiente. Las corridas del sistema contienen situaciones de evasión relativamente homogéneas. Un LoRA entrenado sobre ese conjunto podría sobreajustar a los escenarios vistos y degradar la generalización en configuraciones urbanas no ensayadas.

2. Complejidad de mantenimiento. Un adaptador LoRA es un artefacto de entrenamiento que requiere ser versionado, evaluado y actualizado junto con el modelo base. Para el alcance de esta tesis, el beneficio esperado no justifica el costo de infraestructura. Se deja constancia explícita de que es una alternativa explorada y no adoptada por decisión de alcance, no por omisión.