Cómo escalar aplicaciones LLM sin explotar su cuenta en la nube

"¡Ayuda! nuestros costos de modelo de IA están a través del techo!" Mientras que ChatGPT y sus primos han desatado una agitación de aplicaciones alimentadas por IA, la realidad de construir aplicaciones basadas en LLMs es más compleja que lanzar una llamada de API en una interfaz web. Cada día, mi LinkedIn alimenta sobrecargas con nuevos productos "powered por IA".Algunos analizan documentos legales, otros escriben copias de marketing, y unos pocos valientes incluso intentan automatizar el desarrollo de software.Estas "empresas de envasado" (como a veces se llaman despiadadamente) pueden no estar capacitando sus propios modelos, pero muchos están resolviendo problemas reales para los clientes y encontrando un verdadero producto-mercado adecuado basado en las demandas actuales de las empresas.El secreto? Pero aquí está la cosa: Incluso cuando no está entrenando modelos desde cero, escalar una aplicación de IA de la prueba de concepto a la producción es como navegar por un laberinto blindfolded.Tienes que equilibrar el rendimiento, la fiabilidad y los costos al tiempo que mantiene a tus usuarios felices y a tu equipo financiero de tener un ataque al corazón colectivo. Para comprenderlo mejor, rompamos esto con un ejemplo del mundo real. Imagínese que estamos construyendo “ResearchIt” (no un producto real, pero soporte conmigo), una aplicación que ayuda a los investigadores a digerir artículos académicos. ¿Quiere un resumen rápido de esa sección de metodología densa? ¿Necesita extraer los hallazgos clave de un artículo de 50 páginas? Version 1.0: The Naive Approach Versión 1.0: The Naive Approach Estamos montando alto en el tren de hip-hop de OpenAI - Nuestra primera versión es hermosamente simple: El investigador sube fragmentos de un artículo (secciones específicas y relevantes) Nuestro backend transmite el texto a GPT-5 con una prompt como "Usted es un ayudante de investigación útil. Analizar el siguiente texto y entregar insights estrictamente de la sección proporcionada por el usuario......" La magia ocurre, y nuestros usuarios obtienen sus insights La simplicidad es hermosa. ¿El coste? A medida que más investigadores descubren nuestra herramienta, nuestras facturas mensuales de API comienzan a parecer números de teléfono.El problema es que estamos enviando todas las consultas a GPT-5, el Rolls-Royce de modelos de idiomas, cuando una Toyota Corolla a menudo lo haría bien. Sí, GPT-5 es potente, con su ventana de contexto de 128k y fuertes capacidades de razonamiento, pero a $ 1,25 por 1M de tokens de entrada y $ 10 por 1M de tokens de salida, los costos se suman rápidamente. Para tareas más simples como la resumida o la clasificación, los modelos más pequeños como GPT-5 mini (alrededor del 20% del coste), GPT-5 nano (alrededor del 4%), o Gemini 2.5 Flash-Lite (alrededor del 5%) proporcionan grandes resultados a una fracción del precio. Los modelos de código abierto como el LLaMA de Meta (3 o 4 series) o varios modelos de Mistral o también ofrecen opciones flexibles y rentables para tareas generales o específicas de dominio, aunque su ajuste es a menudo innecesario para cargas de trabajo más ligeras. La elección realmente depende de lo siguiente: Calidad de salida: ¿Puede el modelo proporcionar consistentemente la precisión que necesita su aplicación? ¿El modelo soporta el lenguaje con el que desea trabajar? Velocidad de respuesta: ¿Los usuarios esperarán esos milisegundos adicionales para obtener mejores resultados?El tiempo de respuesta típico para cualquier aplicación debe estar dentro de la marca de 10 segundos para que los usuarios no pierdan el interés, por lo que la velocidad definitivamente importa. Integridad de datos: ¿Cuán sensibles son sus datos y cuáles son sus requisitos de privacidad? Restricciones de recursos: ¿Cuál es su presupuesto, tanto en términos de costes como de tiempo de ingeniería? Para nuestro analista de trabajo de investigación, no necesitamos poesía sobre la física cuántica; necesitamos un resumen fiable y rentable. Bottom Line: Conozca sus necesidades de aplicación Bottom Line: Conozca sus necesidades de aplicación Elija su LLM basado en sus requisitos reales, no pura potencia.Si necesita una configuración rápida, los modelos propietarios pueden justificar el coste.Si la asequibilidad y la flexibilidad importan más, los modelos de código abierto son una opción fuerte, especialmente cuando los pequeños compromisos de calidad son aceptables (aunque puede haber alguna infraestructura sobrecargada). Los investigadores aman cómo resume artículos académicos densos, y nuestra base de usuarios está creciendo rápidamente. Pero ahora, quieren más; en lugar de simplemente resumir las secciones que suben, quieren la flexibilidad para hacer preguntas dirigidas a través de todo el artículo de una manera efectiva. Suena simple, ¿verdad? No tan rápido. Los trabajos académicos son largos. Incluso con el generoso límite de token de 128K de GPT-5, el envío de documentos completos por consulta es un overkill caro. Además, los estudios han demostrado que a medida que la longitud del contexto aumenta, el rendimiento del LLM puede , que es perjudicial cuando se realiza una investigación de vanguardia. degrade degrade Entonces, ¿cuál es la solución? Version 2.0: Smarter chunking and retrieval Versión 2.0: Chunking y recuperación más inteligentes La pregunta clave aquí es ¿cómo escalamos para satisfacer este requisito sin poner en fuego nuestra factura de API y también mantener la precisión en el sistema? **Answer is: \ (RAG). En lugar de descargar todo el documento en el LLM, recuperamos de forma inteligente las secciones más relevantes antes de la consulta. De esta manera no necesitamos enviar el documento entero cada vez al LLM para conservar los tokens, sino también asegurarnos de que los pedazos relevantes se recuperen como contexto para que el LLM responda usando. Generación Retrieval aumentada Generación Retrieval aumentada There are 3 important aspects to consider here: El chunking Storage and chunk retrieval Refinamiento utilizando técnicas avanzadas de recuperación. Step 1: Chunking – Splitting the Document Intelligently Before we can retrieve relevant sections, we need to break the paper into manageable chunks. A naive approach might split text into fixed-size segments (say, every 500 words), but this risks losing context mid-thought. Imagine if one chunk ends with: "The experiment showed a 98% success rate in..." …and the next chunk starts with: "...reducing false positives in early-stage lung cancer detection." Neither chunk is useful in isolation. Instead, we need a semantic chunking strategy: : Use document structure (titles, abstracts, methodology, etc.) to create logical splits. Section-based chunking Deslizamiento de la ventana: sobrepase los trozos ligeramente (por ejemplo, sobrepase de 200 tokens) para preservar el contexto a través de las fronteras. Chunking adaptativo: ajuste dinámico de los tamaños de las piezas en función de los límites de la frase y los temas clave. Section-based chunking Fenómeno de ventana chunking Adaptación del chunking Paso 2: almacenamiento y recuperación inteligentes Una vez que tus fragmentos de documentos estén listos, el siguiente reto es almacenarlos y recuperarlos de manera eficiente. Con las aplicaciones LLM modernas que manejan millones de fragmentos, tu elección de almacenamiento afecta directamente al rendimiento. Los enfoques tradicionales que separan el almacenamiento y la recuperación a menudo caen en falta. En cambio, la arquitectura de almacenamiento debe diseñarse con la recuperación en mente, ya que los diferentes patrones ofrecen distintos compromisos para la velocidad, la escalabilidad y la flexibilidad. La distinción convencional de usar bases de datos relacionales para datos estructurados y NoSQL para datos no estructurados todavía se aplica, pero con un giro: las aplicaciones LLM almacenan no sólo texto sino representaciones semánticas (embeddings). En una configuración tradicional, los fragmentos de documentos y sus incorporaciones pueden almacenarse en PostgreSQL o MongoDB. Esto funciona para aplicaciones de pequeña a mediana escala, pero tiene limitaciones claras a medida que crecen los datos y el volumen de consultas. The challenge here isn't storage, it's the retrieval mechanism. Traditional databases excel at exact matches and range queries, but they weren't built for semantic similarity searches. You'd need to implement additional indexing strategies or use extensions like to enable vector similarity searches. This is where vector databases truly shine - they’re purpose-built for the store-and-retrieve pattern that LLM applications demand - treating embeddings as the primary attribute for querying, optimizing specifically for nearest neighbour searches. The real magic lies in how they handle similarity calculations. While traditional databases often require complex mathematical operations at query time, vector databases use specialized indexing structures such as (Mundo pequeño navegable jerárquico) o Índice de archivo invertido) para hacer que las búsquedas de similitud sean explosivamente rápidas. pgvector HNSW IVF pgvector HNSW El IVF They typically support two primary similarity metrics: Distancia Euclidiana: Mejor adecuada cuando las diferencias absolutas entre vectores son importantes, especialmente útil cuando las incorporaciones codifican relaciones jerárquicas. Similaridad cosina: elección estándar para la búsqueda semántica - se centra en la dirección de los vectores en lugar de la magnitud. Esto significa que dos documentos con significados similares pero de longitudes diferentes todavía pueden coincidir de manera efectiva. Choosing the right vector database is critical for optimizing retrieval performance in LLM applications, as it impacts scalability, query efficiency, and operational complexity. HNSW-based solutions like y ofrecen una búsqueda rápida de ANN con un llamado eficiente: manejan la escalación automáticamente, lo que los convierte en ideales para cargas de trabajo dinámicas con una sobrecarga operacional mínima. (IVF-based) offer more control and cost-effectiveness at scale, but require careful tuning. pgvector integrated with Postgres enables hybrid search, though it may hit limits under high-throughput workloads. The choice finally depends on workload size, query patterns, and operational constraints. Pinecón Weaviate Milvus Pinecón Weaviate Milvus Paso 3: Estrategias avanzadas de recuperación Building an effective retrieval system requires more than just running a basic vector similarity search. While dense embeddings allow for powerful semantic matching, real-world applications often require additional layers of refinement to improve accuracy, relevance, and efficiency. By combining multiple retrieval methods and leveraging Large Language Models (LLMs) for intelligent post-processing, we can significantly enhance retrieval quality. Un desafío común en los sistemas de búsqueda es equilibrar la precisión y la recogida. La búsqueda basada en palabras clave (por ejemplo, BM25, TF-IDF) es excelente para encontrar coincidencias exactas de términos, pero lucha con la comprensión semántica. Por otro lado, la búsqueda vectorial (por ejemplo, FAISS, HNSW o IVFFlat) sobresale en la captura de relaciones semánticas, pero a veces puede devolver resultados relacionados que pierden palabras clave cruciales. To overcome this, a hybrid retrieval strategy combines the strengths of both methods. Esto implica: Retrieving candidates – ejecuta tanto una búsqueda de palabras clave como de similitud vectorial en paralelo. Resultados de fusión: controlar la influencia de cada método de búsqueda basado en el tipo de consulta y las necesidades de la aplicación. Reranking for optimal ordering – ensuring the most relevant information appears at the top based on semantic requirements. Otro desafío es que la búsqueda vectorial tradicional recupera las incorporaciones más cercanas de top-K. LLMs se basan en ventanas de contexto, lo que significa que seleccionar ciegamente los resultados de top-K podría introducir información irrelevante o perder detalles cruciales. Una solución a este problema es utilizar el propio LLM para el refinamiento. Más específicamente, enviamos a los candidatos recuperados a un LLM para verificar la coherencia y relevancia basada en la pregunta del usuario. Some techniques that are used for LLM refinement are as follows: Filtrado de coherencia semántica: En lugar de alimentar los resultados de top-K en bruto, el LLM evalúa si los documentos recuperados siguen una progresión lógica relacionada con la consulta. Reorganización basada en la relevancia: modelos como Cohere Rerank, BGE o MonoT5 pueden reevaluar los documentos recuperados, capturar patrones de relevancia finamente granulados y mejorar los resultados más allá de las puntuaciones de similitud cruda. Expansión del contexto con la recuperación iterativa: la recuperación estática puede perder información indirectamente relevante. los LLM pueden identificar brechas, generar consultas de seguimiento y ajustar la estrategia de recuperación de forma dinámica para recoger el contexto que falta. Filtros de coherencia semántica Relevance-Based Reranking Context Expansion with Iterative Retrieval Now, with these updates, our system is better equipped to handle complex questions across multiple sections of a paper, while maintaining accuracy by grounding responses strictly in the provided content. But what happens when a single source isn't enough? Some questions require synthesizing information across multiple papers or performing calculations using equations from different sources - challenges that pure retrieval can't solve. Version 3.0 - Building a Comprehensive and Reliable System Versión 3.0 - Construir un sistema integral y fiable Por este punto, “ResearchIt” ha madurado de un simple sistema de respuesta a preguntas en un asistente de investigación capaz que extrae secciones clave de los artículos cargados, destaca los métodos y resume el contenido técnico con precisión. Lo que comenzó como un sistema diseñado para resumir o interpretar un solo artículo se ha convertido ahora en una herramienta que los investigadores quieren usar para el razonamiento profundo y cross-domain. The new wave of questions looks like: “Which optimization techniques for transformers demonstrate the best efficiency improvements when combining insights from benchmarks, open-source implementations, and recent research papers?” “¿Cómo se alinean los resultados de compresión de modelos reportados en este artículo con el rendimiento reportado en otros documentos o conjuntos de datos de referencia?” Ya no son tareas simples de recuperación. - La capacidad de integrar e interpretar información compleja, planificar y adaptarse, utilizar herramientas de manera efectiva, recuperarse de errores y producir síntesis basada en evidencias. multi-source reasoning Despite its strong comprehension abilities, “ResearchIt” 2.0 struggles with two major limitations when reasoning across diverse information sources: Análisis transversal: Cuando las respuestas requieren tanto interpretación como cálculo (por ejemplo, extraer FLOPs o precisión de las tablas y compararlas entre condiciones). Síntesis Cross-Source: Cuando los datos relevantes viven en múltiples sistemas - PDFs, registros de experimentos, reposo de GitHub o CSV estructurados - y el modelo debe coordinar la búsqueda, fusionar los hallazgos conflictivos y producir una explicación coherente. These issues aren’t just theoretical. They reflect real-world challenges in AI scalability. As data ecosystems grow more complex, organizations need to move beyond basic retrieval toward reasoned orchestration - systems that can plan, act, evaluate, and continuously adapt. Tomemos la primera pregunta en torno al análisis de las técnicas de optimización de transformadores: ¿cómo resolveríamos este problema como humanos? A group of researchers or students would work on “literature review, i.e, collating papers on the topics, researching open source github repos, and identifying benchmark datasets. They would then extract data and metrics like FLOPs, latency, accuracy from these resources, normalize and compute aggregations and validate the results produced. This is not a one-shot process; it’s iterative, involving multiple rounds of refinement, data validation, and synthesis, after which an aggregated summary of verified results would be generated. So, what exactly did we do here? Break down the overarching question into smaller, focused subproblems - which sources to search, what metrics to analyze, and how comparisons should be run. Consult domain experts or trusted sources to fill knowledge gaps, cross-verify metrics, and interpret trade-offs. Finally, synthesize the insights into a cohesive, evidence-based conclusion, comparing results and highlighting consistent or impactful findings through iterations. Esto es, en esencia, la orquestación razonada - el proceso coordinado de planificar, recoger, analizar y sintetizar información a través de múltiples sistemas y perspectivas. Step 1: Chain of Thought/ Planning Para abordar el primer aspecto, la capacidad de razonar a través de múltiples pasos antes de responder, el concepto de (CoT) se introdujo. CoT permite que los modelos planifiquen antes de la ejecución, provocando un razonamiento estructurado que mejora su interpretabilidad y coherencia.Por ejemplo, en el análisis de las técnicas de optimización de transformadores, un modelo CoT primero delinearía su camino de razonamiento - definiendo el alcance (entrenamiento de eficiencia / rendimiento del modelo / escalabilidad), identificando fuentes relevantes, seleccionando criterios de evaluación y el método de comparación y estableciendo una secuencia de ejecución. Chain of Thought Chain of Thought Este enfoque de razonamiento estructurado se convirtió en la base para las orquestaciones basadas en LangChain. A medida que las preguntas se volvían más complejas, una única "cadea" de razonamiento evolucionó en los enfoques Tree of Thought (ToT) o Graph of Thought (GoT) - permitiendo el razonamiento ramificado y los comportamientos de "pensamiento adelante", donde los modelos exploran múltiples vías posibles de solución antes de converger en el mejor. Of course, adopting these reasoning-heavy models introduces practical considerations - primarily, cost. Running multi-step reasoning chains is computationally expensive, so model choice matters. Current options include: Modelos de código cerrado como los o3 y o4-mini de OpenAI, que ofrecen alta calidad de razonamiento y fuertes capacidades de orquestación. Alternativas de código abierto como DeepSeek-R1, que proporcionan razonamiento transparente con más flexibilidad / esfuerzo de ingeniería para la personalización. While non-thinking LLMs (like LLaMA 3) can still emulate reasoning through CoT prompting, true CoT or ToT models inherently perform structured reasoning natively. For now, let’s assume we’re willing to invest in a top-tier model capable of genuine, interpretable reasoning and multi-source orchestration. Step 2: Multi-source workflows- Function Calling to Agents Breaking down complex problems into logical steps is only half the battle. The system must then coordinate across different specialized tools - each acting as an "expert" - to answer sub-questions, execute tasks, gather data, and refine its understanding through iterative interaction with its environment. Inauguración Introducción as the first step to address this situation. Function calling/ tools gave the LLMs its first real ability to En lugar de predecir simplemente el texto, proporciona al modelo un conjunto de herramientas, por ejemplo, funciones como o and the model decides which one to call, when to call it, and in what order. Let’s take a simple example: function calling Tome acción search_papers(), extract_table(), Cálculo estadístico ( Función de llamada Tareas: “Cálculo de la precisión promedio reportada para el ajuste perfecto BERT”. Un modelo que utiliza la llamada de funciones podría responder ejecutando una cadena lineal como esta: search_papers("precisión de ajuste perfecto de BERT") extract_table() for each paper calculate_statistics() to compute the mean This dummy example of a simple deterministic pipeline where an LLM and a set of tools are orchestrated through predefined code paths is straightforward and effective and can often serve the purpose for a variety of use cases. However, it’s and Cuando se requiere una mayor complejidad, un podría ser la mejor opción cuando se necesita flexibilidad, mejor rendimiento de tareas y toma de decisiones basadas en modelos a escala (con la compensación de la latencia y el coste). linealidad non-adaptive Flujo de trabajo agente Flujo de trabajo agente Los flujos de trabajo de agentes iterativos son sistemas que no solo ejecutan una vez, sino que Al igual que un investigador humano, el modelo aprende a revisar sus pasos, refinar sus consultas y reconciliar datos conflictivos antes de sacar conclusiones. Reflexionar, revisar y reiniciar Think of it as a well-coordinated research lab, where each member plays a distinct role: Agente de recuperación: El explorador de información. expande la consulta inicial, ejecuta búsquedas semánticas y de palabras clave a través de artículos de investigación, API, reposo de github y conjuntos de datos estructurados, asegurándose de que no se ignore ninguna fuente relevante. El agente de extracción: El wrangler de datos. Analiza PDFs, tablas y salidas JSON, luego estandariza los datos extraídos - normalizando las métricas, reconciliando unidades y preparando entradas limpias para el análisis a continuación. El analista realiza los cálculos necesarios, pruebas estadísticas y comprobaciones de coherencia para cuantificar las tendencias y verificar que los datos extraídos tienen sentido. Validation Agent: The quality gatekeeper. It identifies anomalies, missing entries, or conflicting findings, and if something looks off, it automatically triggers re-runs or additional searches to fill the gaps. Synthesis Agent: The integrator. It pulls together all verified insights and composes the final evidence-backed summary or report. Each one can request clarifications, rerun analyses, or trigger new searches when context is incomplete, essentially forming a self-correcting loop - an evolving dialogue among specialized reasoning systems that mirror how real research teams work. Para traducir esto en un ejemplo más concreto de cómo estos agentes entrarían en juego para nuestra cuestión de eficiencia de transformadores: Initial Planning (Reasoning LLM): The orchestrator begins by breaking the task into sub-objectives discussed before. First Retrieval Loop: The Retrieval Agent executes the plan by gathering candidate materials — academic papers, MLPerf benchmark results, and open-source repositories related to transformer optimization. During this step, it detects that two benchmark results reference outdated datasets and flags them for review, prompting the orchestrator to mark those as lower confidence. Extraction & Computation Loop: Next, the Extraction Agent processes the retrieved documents, parsing FLOPs and latency metrics from tables and converting inconsistent units (e.g., TFLOPs vs GFLOPs) into a standardized format. The cleaned dataset is then passed to the Computation Agent, which calculates aggregated improvements across optimization techniques. Meanwhile, the Validation Agent identifies an anomaly - an unusually high accuracy score from one repository. It initiates a follow-up query and discovers the result was computed on a smaller test subset. This correction is fed back to the orchestrator, which dynamically revises the reasoning plan to account for the new context. Iterative Refinement: Following the Validation Agent’s discovery that the smaller test set introduced inconsistencies in the reported results - the Retrieval Agent initiates a secondary, targeted search to gather additional benchmark data and papers on quantization techniques. The goal is to fill missing entries, verify reported accuracy-loss trade-offs, and ensure comparable evaluation settings across sources. The Extraction and Computation Agents then process this newly retrieved data, recalculating averages and confidence intervals for all optimization methods. An optional Citation Agent could examine citation frequency and publication timelines to identify which techniques are gaining traction in recent research. Final Synthesis: Once all agents agree, the orchestrator compiles a verified, grounded summary like - “ ” Across 14 evaluated studies, structured pruning yields 40–60 % FLOPs reduction with < 2 % accuracy loss (Chen 2023; Liu 2024). Quantization maintains ≈ 99 % accuracy while reducing memory by 75 % (Park 2024). Efficient-attention techniques achieve linear-time scaling (Wang 2024) with only minor degradation on long-context tasks (Zhao 2024). Recent citation trends show a 3× rise in attention-based optimization research since 2023, suggesting a growing consensus toward hybrid pruning + linear-attention approaches. What’s powerful here isn’t just the end result - it’s the . Proceso Cada agente contribuye, desafía y refina el trabajo de los demás hasta que surge una conclusión estable y multi-fuente. y Comunicación que juntos permiten la colaboración sin problemas entre agentes de razonamiento especializados. MCP estándariza cómo los modelos y herramientas intercambian información estructurada -como documentos recuperados, tablas analizadas o resultados calculados - asegurando que cada agente pueda comprender y construir sobre los resultados de los demás. Complementando esto, la comunicación A2A permite a los agentes coordinarse directamente entre sí - compartir estados de razonamiento intermedio, solicitar aclaraciones o desencadenar acciones de seguimiento sin intervención. Juntos, MCP y A2A forman la columna vertebral del razonamiento colaborativo: una infraestructura flexible y modular que permite a los agentes planificar, actuar y refinar colectivamente en tiempo real. Protocolo de modelo de contexto (MCP) Agente a agente (A2A) Protocolo de modelo de contexto (MCP) Agente a agente (A2A) Step 3: Ensuring Groundedness and Reliability En esta etapa, ahora tienes un sistema de agentes que es capaz de descomponer cuestiones de investigación relativamente complejas y abstractas en pasos lógicos, recopilar datos de múltiples fuentes, realizar cálculos o transformaciones donde sea necesario, y reunir los resultados en un resumen coherente, respaldado por evidencias. hechos - predicen el próximo token más probable basado en patrones en sus datos de entrenamiento. que significa que su salida es fluida y convincente, pero no siempre Mientras que los conjuntos de datos mejorados y los objetivos de formación ayudan, la verdadera salvaguardia proviene de la adición de mecanismos que pueden verificar y corregir lo que el modelo produce en tiempo real. Conozca correct Here are a few techniques that make this possible: Rule-Based Filtering: Define domain-specific rules or patterns that catch obvious errors before they reach the user. For example, if a model outputs an impossible metric, a missing data field, or a malformed document ID, the system can flag and regenerate it. Cross-Verification: Automatically re-query trusted APIs, structured databases, or benchmarks to confirm key numbers and facts. If the model says “structured pruning reduces FLOPs by 50%,” the system cross-checks that against benchmark data before accepting it. Self-Consistency Checks: Generate multiple reasoning passes and compare them. Hallucinated details tend to vary between runs, while factual results remain stable - so the model keeps only the majority-consistent conclusions. Juntos, estas capas forman la salvaguarda final - cerrando el ciclo de razonamiento.Cada respuesta que produce el sistema no sólo está bien estructurada sino que también se . Verificado Y aquí está - lo que comenzó como un modelo basado en la búsqueda simple se ha desarrollado ahora en un robusto asistente de investigación: uno que no solo responde a preguntas y preguntas básicas, sino que también aborda preguntas analíticas profundas mediante la integración de datos de múltiples fuentes, la ejecución de cálculos y la producción de conocimientos fundamentados, todo mientras se defiende activamente contra las alucinaciones y la desinformación.