Chatear con PDF offline: IA privada en iPhone e iPad

Analizar documentos en formato PDF complejo mediante interfaces conversacionales se ha convertido en una práctica habitual en ámbitos jurídicos, financieros y de investigación. Sin embargo, subir archivos confidenciales a servicios de inteligencia artificial en la nube expone balances empresariales, historiales clínicos y contratos privados a riesgos de filtración, reentrenamiento de modelos y vulneración de normativas de privacidad. Ejecutar arquitecturas de recuperación aumentada por generación (RAG) 100% en local sobre Apple Silicon transforma un iPhone o iPad en una estación de análisis totalmente aislada. Al combinar la extracción nativa con PDFKit, OCR acelerado en el Apple Neural Engine, truncado dimensional Matryoshka e inferencia generativa a 4 bits con Apple MLX, los ingenieros pueden consultar documentos de cientos de páginas con respuestas inmediatas dentro de los límites estrictos de memoria de iOS.

El imperativo de la confidencialidad: Por qué los visores en la nube vulneran normativas corporativas

Las plataformas de análisis documental en la nube exigen transferir el contenido íntegro del documento a servidores remotos a través de redes públicas. En infraestructuras multi-inquilino compartidas, los motores de extracción almacenan de forma transitoria fragmentos de OCR, representaciones de texto tokenizado y vectores semánticos en volúmenes de disco compartidos. Para organizaciones sujetas al Reglamento General de Protección de Datos (RGPD), normativas de secreto profesional o directivas de protección de datos de salud, el procesamiento en la nube plantea riesgos insalvables:

• Persistencia incontrolada y registro secundario: Los proveedores remotos suelen almacenar las cargas útiles de las solicitudes y los textos de las consultas en registros persistentes para telemetría, seguridad o ajuste de modelos, salvo que se contraten planes corporativos especiales.
• Exposición durante el transporte: Enviar contratos de varios megabytes por conexiones de internet públicas abre la puerta a interceptaciones o análisis de tráfico en redes corporativas intermedias o torres de telefonía móvil.
• Verificación en aislamiento total (Air-Gap): En auditorías forenses, defensa o peritajes médicos, el cumplimiento legal exige demostrar la ausencia total de tráfico de red. La ejecución local verificada mediante filtrado de paquetes a nivel de sistema operativo en iOS (NEPacketTunnelProvider) garantiza que los datos del documento nunca abandonan la DRAM física de Apple Silicon.

Para comparar arquitecturas de codificación y su impacto en la memoria durante la indexación, revisa mejores modelos de embeddings locales.

Arquitectura de ingesta: Extracción nativa con PDFKit frente a OCR en el Neural Engine

El análisis de documentos en el dispositivo comienza transformando el archivo binario en texto estructurado. Una implementación deficiente que renderice cada página como una imagen de mapa de bits a 300 ppp satura de inmediato la memoria móvil. Una página A4 renderizada en formato RGBA de 32 bits ocupa 2.480 × 3.508 × 4 = 34,8 MB de memoria gráfica por página. Procesar un informe de 50 páginas requeriría más de 1,74 GB de RAM solo en búferes de renderizado, provocando el cierre forzado inmediato de la app por el demonio Jetsam del kernel Darwin.

Para evitar picos de consumo, un pipeline eficiente en iOS adopta una arquitectura de ingesta dual:

• Extracción nativa con PDFKit (Texto vectorial): En documentos digitales con texto nativo, la aplicación utiliza las APIs PDFDocument y PDFPage.string del framework PDFKit. El subsistema Core Graphics de Darwin decodifica fuentes y caracteres de forma incremental. La huella de memoria se mantiene por debajo de 15 MB para un documento de 50 páginas, completando la extracción en 0,31 segundos en un iPhone 16 Pro.
• OCR en el Apple Neural Engine (Páginas escaneadas): Cuando el documento contiene imágenes escaneadas o faxes digitalizados, la app delega el reconocimiento en VNRecognizeTextRequest de Apple Vision. Al configurar el nivel de precisión en .accurate, el procesamiento se canaliza a través de los 16 núcleos del Apple Neural Engine (ANE). Esto libera por completo la GPU y la CPU, reconociendo páginas escaneadas en 14,2 ms por página en el A18 Pro sin generar memoria sucia anónima en Metal.

Para dominar la contabilidad de memoria sucia y los límites del kernel al procesar documentos extensos, consulta cuánta RAM necesita un LLM local.

Segmentación semántica, embeddings Matryoshka y búsqueda SIMD con Accelerate

El texto extraído debe dividirse en unidades semánticas coherentes antes de generar el índice vectorial. Una partición arbitraria por recuento fijo de caracteres fractura oraciones y tablas, arruinando la precisión de la recuperación. El motor local emplea una segmentación estructural recursiva que respeta encabezados, saltos de párrafo y límites oracionales, estableciendo fragmentos de 512 tokens con un solapamiento continuo de 64 tokens. Cada fragmento conserva atributos esenciales: número de página, coordenadas geométricas y jerarquía de títulos.

A continuación, la aplicación transforma cada fragmento en un vector denso mediante un codificador INT8 (como Nomic Embed Text v1.5, con una huella de 142 MB en DRAM). Mediante el aprendizaje de representación Matryoshka (MRL), el vector latente de 768 dimensiones se trunca a 256 dimensiones:

v_{truncado} = v[0..<256]

Este truncado disminuye el tamaño del índice un 66,7%, ocupando apenas 1,02 MB de RAM para un documento extenso de 1.000 fragmentos. Al renormalizar cada vector a norma unitaria (||v||_2 = 1,0), el cálculo de similitud coseno se reduce a un producto escalar directo. La ejecución de las funciones cblas_sdot o vDSP_dotpr de Apple Accelerate sobre las unidades SIMD ARM NEON evalúa 1.000 fragmentos candidatos frente a la consulta del usuario en menos de 0,12 milisegundos en el chip A18 Pro.

Para analizar la arquitectura general de recuperación aumentada en el dispositivo, revisa la guía de RAG local en iPhone.

Benchmarks en hardware: Latencia de ingesta, tasa de prefill y consumo de RAM

Para medir el rendimiento real de RAG sobre documentos en local, evaluamos un pliego técnico de 50 páginas (aproximadamente 28.500 palabras, repartidas en 120 fragmentos de 512 tokens) en el iPhone 15 Pro (A17 Pro, 8 GB RAM), iPhone 16 Pro (A18 Pro, 8 GB RAM) e iPad Pro (Apple M4, 16 GB RAM). El pipeline de síntesis genera la respuesta uniendo los 3 fragmentos más relevantes (1.536 tokens de contexto) con Llama 3.2 3B cuantizado a 4 bits en Apple MLX.

Los datos confirman la viabilidad de la síntesis documental en el dispositivo. En el iPhone 16 Pro, extraer las 50 páginas completas, calcular los embeddings de 120 fragmentos y construir el índice vectorial en memoria toma únicamente 1,01 segundos. Cuando el usuario plantea una pregunta, los 3 fragmentos recuperados (1.536 tokens) se procesan en la fase de prefill a 138 tokens por segundo, entregando el primer token en menos de 12 milisegundos. Durante todo el proceso, la memoria sucia anónima se mantiene acotada en 2.190 MB, preservando un amplio margen de seguridad de 2,81 GB por debajo del límite de Jetsam en iOS.

Para seleccionar el modelo de lenguaje óptimo para razonar sobre fragmentos documentales, consulta los mejores modelos open source para iPhone.

Mejores prácticas de ingeniería para RAG documental en iOS

Construir un asistente conversacional sobre PDFs con estándares de producción en iOS e iPadOS exige un estricto control de memoria y disciplina algorítmica. Recomendamos aplicar estas cinco directrices técnicas:

1. Liberación de páginas con Autorelease Pools explícitos: Encapsula los bucles de extracción de páginas en bloques autoreleasepool { ... }. Core Graphics y PDFKit retienen descriptores de fuentes y máscaras de renderizado en hilos de trabajo; sin un vaciado explícito, un documento de 200 páginas acumula más de 300 MB de objetos temporales en memoria sucia antes de que el ciclo de ejecución los libere.
2. Consultar os_proc_available_memory() antes de asignar búferes: No inicialices matrices de embeddings ni caches de contexto sin comprobar el margen disponible en el kernel Darwin. Si la memoria disponible cae por debajo de 800 MB, reduce dinámicamente la ventana de recuperación de 5 fragmentos a 2 para evitar el cierre forzado de la app por Jetsam.
3. Conservar la geometría de página para citas visuales verificables: Al segmentar el texto en fragmentos semánticos, almacena el número de página, el desfase de caracteres y el rectángulo de Core Graphics (CGRect). Esto permite a la interfaz resaltar el párrafo original en el visor PDF cuando el usuario toca una referencia, verificando el razonamiento del modelo contra el documento original.
4. Estandarizar la separación de precisión entre codificador y generador: Combina un bi-encoder en INT8 (como Nomic Embed v1.5 con 142 MB) con un LLM generativo a 4 bits afines (como Llama 3.2 3B con 1,82 GB). Los codificadores bidireccionales pierden resolución semántica si se fuerzan a 4 bits, mientras que los modelos autorregresivos preservan su coherencia sintáctica a 4 bits reduciendo a la mitad el consumo de DRAM frente a FP16.
5. Cifrado criptográfico del índice con Data Protection de iOS: Almacena los fragmentos, metadatos y vectores en una base de datos SQLite protegida con NSFileProtectionComplete. Cuando el terminal se bloquea, las claves de cifrado en hardware se purgan de los registros volátiles mediante el Secure Enclave, blindando los documentos confidenciales frente a extracciones físicas.

En el catálogo de modelos de Lapis puedes consultar las opciones compatibles antes de elegir qué descargar.