Inspirado en la publicación/artículo de blog de ICLR 2026, La paradoja del éxito del 99%: cuando la recuperación casi perfecta equivale a selección aleatoria
Como doctor en recuperación de información formado en Edimburgo por el Laboratorio de recuperación de información multimedia de Victor Lavrenko en Edimburgo, donde me formé a finales de la década de 2000, durante mucho tiempo he visto la recuperación a través del marco del pensamiento tradicional de RI:
¿Recuperamos al menos un fragmento relevante? ¿El recuerdo aumentó? ¿Mejoró el ranking? ¿La calidad de las respuestas posteriores parecía aceptable en un punto de referencia?
Esas siguen siendo preguntas útiles. Pero después de leer el trabajo reciente sobre Bits over Random (BoR), creo que están incompletos para los sistemas Agentic que muchos de nosotros estamos construyendo ahora.
La entrada del blog de ICLR agudizó algo que había sentido durante un tiempo en los sistemas de LLM de producción: la calidad de la recuperación debe tener en cuenta tanto la cantidad de buen contenido que encontramos como la cantidad de material irrelevante que traemos consigo. En otras palabras, a medida que aumentamos nuestra recuperación, también aumentamos el riesgo de contaminación del contexto.
Lo que hace que BoR sea útil es que nos brinda un lenguaje para esto. BoR nos dice si la recuperación es genuinamente selectiva o si estamos logrando el éxito principalmente llenando la ventana de contexto con más material. Cuando el BoR cae, es una señal de que el paquete recuperado se está volviendo menos discriminativo en relación con el azar. En la práctica, esto a menudo se correlaciona con que el modelo se vea obligado a leer más basura, más superposiciones o material menos relevante.
El matiz importante es que BoR no mide directamente lo que el modelo "siente" al leer una indicación. Mide la selectividad de recuperación en relación con el azar. Pero una menor selectividad a menudo va de la mano de un contexto más irrelevante, una contaminación más inmediata, una mayor dilución de la atención y un peor desempeño posterior. En pocas palabras, BoR ayuda a decirnos cuándo la recuperación sigue siendo selectiva y cuándo ha comenzado a degenerar en un relleno de contexto.
Esa idea es mucho más importante para RAG y sus agentes que para la búsqueda clásica.
Por qué los paneles de recuperación pueden engañar a los equipos de agentes
Una de las trampas más fáciles en RAG es mirar su panel de recuperación, ver métricas saludables y concluir que el sistema está funcionando bien. Es posible que veas:
Success@K alto, fuerte recuerdo, una buena métrica de clasificación y una K más grande que parece mejorar la cobertura.
Sobre el papel las cosas pueden parecer mejor pero, en realidad, el agente podría comportarse peor. Su agente puede tener varios problemas, como respuestas difusas a las consultas, uso de herramientas poco confiables o simplemente un aumento en la latencia y el costo del token sin ningún beneficio real para el usuario.
Esta desconexión se produce porque la mayoría de los paneles de recuperación todavía reflejan una visión del mundo de búsqueda humana. Asumen que el consumidor del conjunto recuperado puede hojear, filtrar e ignorar la basura. Los humanos son sorprendentemente buenos en esto. Los LLM no siempre son buenos en eso.
Un LLM no “nota” diez elementos recuperados y se concentra casualmente en los dos mejores como lo haría un analista fuerte. Procesa el paquete completo como contexto rápido. Eso significa que la capa de recuperación está sacando a la superficie evidencia que está dando forma activamente a la memoria de trabajo del modelo.
Es por eso que creo que los equipos de agentes deberían dejar de tratar la recuperación como un problema de clasificación administrativa y comenzar a tratarla como un problema de asignación de presupuesto y razonamiento. Al construir sistemas agentes de alto rendimiento, la pregunta clave es:
¿Recuperamos algo relevante?
y:
¿Cuánto ruido obligamos a procesar el modelo para obtener esa relevancia?
Ésa es la lente hacia la que te empuja BoR, y he descubierto que es muy útil.
La ingeniería de contexto se está convirtiendo en una disciplina de primer nivel.
Una de las razones por las que este artículo me ha llamado la atención es que se ajusta a un cambio más amplio que ya está ocurriendo en la práctica. Los ingenieros de software y los profesionales de ML que trabajan en sistemas LLM se están acercando gradualmente a los ingenieros de contexto.
Eso significa diseñar sistemas que decidan:
qué debe ingresar al mensaje, cuándo debe ingresar, de qué forma, con qué granularidad y qué debe excluirse por completo.
En el software tradicional, nos preocupamos por los límites de la memoria, la computación y las API. En los sistemas LLM, también debemos preocuparnos por la pureza del contexto. La ventana de contexto es un espacio cognitivo controvertido.
Cada pasaje irrelevante, fragmento duplicado, ejemplo débilmente relacionado, definición de herramienta detallada y resultado de recuperación mal sincronizado compite con aquello en lo que más necesita centrarse el modelo. Por eso me gusta la metáfora de la contaminación. El contexto irrelevante contamina el espacio de trabajo del modelo.
El cartel del BoR da a esta intuición una forma más rigurosa al decirnos que deberíamos dejar de evaluar la recuperación sólo en función de si tiene éxito. También deberíamos preguntarnos qué tan mejor es la recuperación en comparación con el azar, en la profundidad (top K elementos recuperados) que realmente estamos usando. Esa es una pregunta muy amigable para los profesionales.
Por qué la sobrecarga de herramientas rompe a los agentes
Aquí es donde creo que el trabajo de BoR se vuelve especialmente importante para los sistemas de agentes del mundo real.
En el RAG clásico, el corpus suele ser grande. Es posible que esté recuperando decenas de miles o millones de fragmentos. En ese régimen, el azar sigue siendo débil durante más tiempo. La selección de herramientas es muy diferente.
En un agente, el modelo puede elegir entre 20, 50 o 100 herramientas. Esto suena manejable hasta que te das cuenta de que, a menudo, varias herramientas son vagamente plausibles para la misma tarea. Una vez que eso sucede, poner todas las herramientas en contexto no es minuciosidad. Es confusión disfrazada de plenitud.
He visto este patrón repetidamente en el diseño de agentes:
el equipo agrega más herramientas, las descripciones se vuelven más largas, aumenta la superposición entre herramientas, el agente comienza a tomar decisiones frágiles o inconsistentes y el primer instinto es ajustar más el mensaje.
Pero a menudo el verdadero problema es arquitectónico, no a nivel de solicitud. Se le pide al modelo que elija en un contexto sobrecargado donde las distinciones son demasiado débiles y demasiado numerosas.
Lo que BoR añade aquí es una forma útil de formalizar algo que la gente a menudo siente sólo de forma intuitiva: hay un punto en el que la tarea de selección se vuelve tan saturada que el modelo ya no demuestra una selectividad significativa.
Por eso prefiero los diseños de agentes con:
Recuperación de herramientas por etapas: limitar la búsqueda en pasos, encontrar primero un pequeño conjunto de herramientas plausibles y luego hacer la elección final de esa lista corta en lugar de de la biblioteca completa a la vez. Enrutamiento de dominio: antes de elegir la herramienta final, significa primero decidir a qué área amplia pertenece la tarea, como búsqueda, CRM, finanzas o codificación, y solo luego seleccionar una herramienta específica dentro de ese dominio. Resúmenes de capacidades comprimidos: presentar cada herramienta con una descripción breve y de alta señal de para qué sirve, cuándo debe usarse y en qué se diferencia de las herramientas cercanas, en lugar de arrojar especificaciones largas y detalladas en el mensaje. Exclusión explícita de herramientas irrelevantes: eliminar deliberadamente herramientas que no son apropiadas para la tarea actual para que el modelo no se distraiga con opciones plausibles pero innecesarias.
En mi experiencia, la elección de herramientas debería tratarse más como una recuperación que como una decoración de mensajes estáticos.
Comprender el BoR a través de la selección de herramientas
Una de las cosas más útiles de BoR es que afina lo que realmente significa top-K en los agentes que utilizan herramientas.
En la recuperación de documentos, aumentar el top-K a menudo significa pasar de los 5 pasajes principales a los 20 o 50 primeros de un corpus muy grande. En la selección de herramientas, el mismo movimiento tiene un carácter muy diferente. Cuando un agente solo tiene una biblioteca de herramientas modesta, aumentar el top-K puede significar pasar de una lista corta de 3 herramientas candidatas a 5, a 8 y, finalmente, a la alternativa familiar pero peligrosa: simplemente proporcione las 15 herramientas para estar seguro.
Esto a menudo mejora la recuperación o el Éxito@K, porque es más probable que la herramienta correcta esté en algún lugar del conjunto visible. Pero esa mejora puede ser engañosa. A medida que K crece, no sólo estás ayudando al enrutador. También está facilitando que un selector aleatorio incluya una herramienta relevante.
Entonces, la verdadera pregunta no es simplemente: ¿el top 8 contenía una herramienta útil con más frecuencia que el top 3? La pregunta más importante es: ¿Mejoró el top 8 una selectividad significativa, o facilitó principalmente la tarea mediante la inclusión por fuerza bruta? Ahí es exactamente donde el BoR se vuelve útil.
Un ejemplo sencillo aclara la intuición. Supongamos que tiene 10 herramientas y, para una determinada clase de tarea, 2 de ellas son realmente relevantes. Si le muestra al modelo solo una herramienta, la probabilidad aleatoria de que aparezca una relevante es del 20 por ciento. Con 3 herramientas, la línea de base aleatoria aumenta bruscamente. Con 5 herramientas, la inclusión aleatoria ya es bastante fuerte. Con 10 herramientas, es 100 por ciento, porque lo has demostrado todo. Entonces sí, Success@K aumenta a medida que aumenta K. Pero el significado de ese éxito cambia. Con K bajo, el éxito indica una discriminación real. Con un K alto, el éxito puede significar simplemente que incluyó suficiente cantidad del menú como para que el fracaso se volviera difícil.
A eso me refiero con ayudar al azar en lugar de a una selectividad significativa.
Esto es importante porque, con herramientas, el problema es peor que una métrica engañosa. Cuando muestra demasiadas herramientas, el mensaje se vuelve más largo, las descripciones comienzan a superponerse, el modelo ve más coincidencias, las distinciones se vuelven más confusas, aumenta la confusión de parámetros y aumenta la posibilidad de elegir una herramienta plausible pero incorrecta. Entonces, aunque mejore el retiro de los mejores K, la calidad de la decisión final puede empeorar. Ésta es la paradoja de las herramientas pequeñas: agregar más herramientas candidatas puede aumentar la cobertura aparente y al mismo tiempo disminuir la capacidad del agente para elegir limpiamente.
Una forma práctica de pensar en esto es que la selección de herramientas a menudo se divide en tres regímenes. En el régimen saludable, K es pequeño en relación con la cantidad de herramientas, y la aparición de una herramienta relevante en la lista corta le indica que el enrutador realmente hizo algo útil. Por ejemplo, 30 herramientas en total, 2 o 3 relevantes, y una lista corta de 3 o 4 todavía parece una selección genuina. En la zona gris, K es lo suficientemente grande como para mejorar el recuerdo, pero la inclusión aleatoria también está aumentando rápidamente. Por ejemplo, 20 herramientas, 3 relevantes, lista corta de 8. Aquí aún puede ganar algo, pero ya debería preguntarse si realmente está enrutando o simplemente ampliando el embudo. Finalmente, está el régimen de colapso, donde K es tan grande que el éxito proviene principalmente de exponer suficiente parte del menú de herramientas para que la selección aleatoria también tenga éxito a menudo. Si tiene 15 herramientas, 3 relevantes y una lista corta de 12 o las 15, entonces “alto recuerdo” ya no dice mucho. Te estás acercando a la exposición a la fuerza bruta.
Operacionalmente, esto me empuja hacia una pregunta mejor. En un sistema de herramientas pequeñas, recomiendo evitar la mentalidad de sobreexposición que pregunta:
¿Qué tamaño debe tener K para que el retiro parezca bueno?
La mejor pregunta es:
¿Qué tan pequeña puede ser mi lista corta sin dejar de conservar un sólido desempeño en la tarea?
Esa mentalidad fomenta el enrutamiento disciplinado.
En la práctica, eso generalmente significa enrutar primero y elegir segundo, mantener la lista corta muy pequeña, comprimir las descripciones de las herramientas para que las distinciones sean obvias, dividir las herramientas en dominios antes de la selección final y probar si aumentar K mejora la precisión de las tareas de un extremo a otro, no solo la recuperación de herramientas. Una comprobación de cordura útil es la siguiente: si darle al modelo todas las herramientas funciona aproximadamente igual que su lista corta de enrutamiento, entonces es posible que su capa de enrutamiento no esté agregando mucho valor. Y si darle al modelo más herramientas mejora la recuperación pero empeora el desempeño general de la tarea, es probable que se encuentre exactamente en el régimen en el que K ayuda más al azar que a la selectividad real.
Cuando cambia el modo de falla: grandes bibliotecas de herramientas
El caso de las herramientas grandes es diferente, y aquí es donde importa un matiz importante. Un universo de herramientas más grande no significa que debamos poner cientos de herramientas en contexto y esperar que el sistema funcione mejor. Simplemente significa que el modo de falla cambia.
Si un agente tiene 1000 herramientas disponibles y solo unas pocas son relevantes, entonces aumentar el top-K de 10 a 50 o incluso 100 aún puede representar una selectividad significativa. El azar permanece más débil durante más tiempo que en el caso de las herramientas pequeñas. En ese sentido, el BoR sigue siendo útil: nos ayuda a evitar que confundamos una exposición más amplia con una mejor ruta. Se pregunta si una lista corta más grande refleja una selectividad genuina o si simplemente ayuda al exponer una porción más grande del espacio de búsqueda.
Pero el BoR no capta aquí todo el problema. Con bibliotecas de herramientas muy grandes, es posible que el problema ya no sea que el azar se haya vuelto demasiado fuerte. El problema puede ser que el modelo simplemente se está ahogando en opciones. Una lista corta de 200 herramientas aún puede ser mejor que la aleatoria en términos de BoR y aun así ser un mensaje terrible. Las descripciones de las herramientas se superponen, proliferan las coincidencias, las distinciones se vuelven más difíciles de mantener y el modelo se ve obligado a razonar sobre un menú semántico abarrotado.
Así pues, el BoR es valioso, pero no suficiente por sí solo. Es mejor para decirnos si una lista corta es genuinamente discriminativa en relación con el azar que si esa lista corta todavía es cognitivamente manejable para el modelo. Por lo tanto, en las grandes bibliotecas de herramientas, necesitamos ambas perspectivas: BoR para medir la selectividad y medidas posteriores, como la calidad de la elección de herramientas, la latencia, la corrección de los parámetros y el éxito de las tareas de un extremo a otro para medir la usabilidad.
BoR nos dice si la recuperación es genuinamente selectiva o si estamos logrando el éxito principalmente llenando la ventana de contexto con más material. Cuando el BoR cae, es una señal de que el paquete recuperado se está volviendo menos discriminativo en relación con el azar. En la práctica, esto a menudo se correlaciona con que el modelo se vea obligado a leer más basura, más superposiciones o material menos relevante. El matiz es que BoR no mide directamente lo que el modelo "siente" al leer una indicación. Mide la selectividad relativa al azar. Pero un BoR bajo es a menudo una señal de advertencia de que se le está pidiendo al modelo que procese una ventana de contexto cada vez más ruidosa.
La implicación del diseño es la misma aunque el motivo difiere. Con conjuntos de herramientas pequeños, la exposición amplia rápidamente se vuelve mala porque ayuda demasiado al azar. Con conjuntos de herramientas muy grandes, la exposición amplia resulta mala porque abruma al modelo. En ambos casos, la respuesta no es meter más en contexto. Es para diseñar mejores rutas.
Mi propia regla general: el modelo debería ver menos, pero más limpio
Si tuviera que resumir el cambio práctico en una frase, sería esta: para los sistemas LLM, más pequeños y más limpios suelen ser mejores que más grandes y completos.
Esto suena obvio, pero muchos sistemas todavía están diseñados como si “más contexto” fuera automáticamente más seguro. En realidad, una vez que existe un nivel básico de evidencia útil, la recuperación adicional puede resultar perjudicial. Aumenta el costo del token y la latencia, pero lo más importante es que amplía el campo de señales competitivas dentro del mensaje.
He llegado a pensar en la construcción rápida en tres capas:
Capa 1: contexto de tarea obligatoria
La instrucción central, las limitaciones y el objetivo inmediato del usuario.
Capa 2: puesta a tierra altamente selectiva
Solo la evidencia de respaldo mínima o las definiciones de herramientas necesarias para el siguiente paso de razonamiento.
Capa 3: desbordamiento opcional
Material que sea meramente plausible, vagamente relacionado o incluido "por si acaso".
La mayoría de las fallas provienen de permitir que la Capa 3 invada la Capa 2. Es por eso que la recuperación debe juzgarse no solo por la cobertura, sino por su capacidad para preservar una Capa 2 limpia.
Donde creo que BoR es especialmente útil
No veo a BoR como un reemplazo para todas las métricas de recuperación. Lo veo como una lente adicional muy útil, sobre todo en estos casos:
1. Elegir K en producción
Muchos equipos aún aumentan el top-K hasta que el retiro parece lo suficientemente bueno. BoR fomenta una pregunta más disciplinada: ¿en qué punto el aumento de K ayuda principalmente al azar en lugar de a una selectividad significativa?
2. Evaluación del enrutamiento de herramientas del agente
Este puede ser el caso de uso más convincente. Los agentes a menudo fallan no porque no exista una buena herramienta, sino porque se presentan simultáneamente demasiadas herramientas casi relevantes.
3. Diagnosticar por qué la calidad aguas abajo cae a pesar de una “mejor recuperación”
Ésta es la paradoja clásica. La cobertura aumenta. La calidad de la respuesta final disminuye. BoR ayuda a explicar por qué.
4. Comparación de sistemas con diferentes profundidades de recuperación
Las tasas de éxito brutas pueden ser engañosas cuando un sistema recupera mucho más material que otro. BoR ayuda a normalizar eso.
5. Prevenir el exceso de confianza en los resultados de los benchmarks
Algunos puntos de referencia pueden ser simplemente demasiado fáciles para la profundidad de recuperación elegida. Un resultado que parezca sólido puede estar más cerca de la suerte de lo que pensamos.
Dónde creo que el BoR puede ser insuficiente por sí solo
Me gusta el artículo, pero no trataría a BoR como la respuesta final a la evaluación de recuperación. Hay al menos algunas advertencias importantes.
En primer lugar, no todas las tareas necesitan sólo un buen elemento. Algunas tareas realmente requieren una síntesis de múltiples pruebas. En esos casos, una visión del estilo del éxito puede subestimar la necesidad de una recuperación más amplia.
En segundo lugar, la utilidad de la recuperación no es binaria. Dos fragmentos pueden contar como “relevantes”, mientras que uno es mucho más procesable, conciso o útil para tomar decisiones para el modelo.
En tercer lugar, la pronta organización sigue siendo importante. Un paquete ruidoso que esté cuidadosamente estructurado puede funcionar mejor que un paquete un poco más limpio, mal ordenado o mal formateado.
Cuarto, el modelo en sí importa. Los diferentes LLM tienen diferente tolerancia al desorden, diferente comportamiento en contextos prolongados y diferente confiabilidad en el uso de herramientas. Una política de recuperación que contamina un modelo puede ser aceptable para otro.
En quinto lugar, y esto es especialmente relevante para grandes bibliotecas de herramientas, BoR nos dice más sobre selectividad que sobre usabilidad. Una lista corta aún puede verse significativamente mejor que la aleatoria y, sin embargo, estar demasiado llena, demasiado superpuesta o demasiado semánticamente confusa para que el modelo la use bien.
Por tanto, no utilizaría BoR de forma aislada. Lo combinaría con:
precisión de las tareas posteriores, análisis de latencia y costo de tokens, calidad de las llamadas a herramientas, corrección de parámetros y alguna medida explícita de limpieza o redundancia rápida.
Aún así, incluso con esas salvedades, el BoR aporta algo importante: nos obliga a dejar de confundir cobertura con selectividad.
Cómo esto cambia la práctica de evaluación para mí
El mayor cambio práctico es que ahora evaluaría sistemas de recuperación más parecidos a este:
Primero, observe las métricas de recuperación estándar. Todavía importan. Lo ideal sería considerar un enfoque de bolsa de métricas, aprovechando múltiples métricas complementarias.
Entonces pregunta:
¿Cuál es la línea de base aleatoria a esta profundidad? ¿Un mayor Success@K realmente demuestra habilidad o simplemente condiciones más fáciles? ¿Cuánto contexto adicional agregamos para obtener esa ganancia? ¿La calidad de las respuestas posteriores mejoró, se mantuvo estable o empeoró? ¿Estamos haciendo que el modelo razone o simplemente haciéndolo leer más?
Para los agentes, iría aún más lejos:
¿Cuántas herramientas estaban visibles en el momento de la decisión? ¿Cuánta superposición existía entre las herramientas candidatas? ¿Podría el sistema haber enrutado primero y seleccionado el segundo? ¿Se le pidió a la modelo que eligiera de una lista corta o de un menú abarrotado?
Se trata de una configuración de evaluación más realista para los tipos de sistemas que muchos equipos están implementando.
La lección más amplia
La lección principal que aprendí del póster de ICLR es mucho más amplia que una única métrica nueva: es que la calidad del sistema LLM depende en gran medida de la limpieza del contexto que construimos alrededor del modelo. Eso tiene consecuencias en toda la pila de Agentic:
recuperación, memoria, enrutamiento de herramientas, planificación de agentes, flujos de trabajo de varios pasos e incluso diseño de interfaz de usuario para sistemas humanos en el circuito.
Los mejores sistemas LLM serán aquellos que expongan la información correcta, en el momento adecuado, en el paquete limpio más pequeño que aún admita la tarea. Ésta es la naturaleza de lo que parece una buena ingeniería de contexto.
Pensamiento final
Durante años, la recuperación consistía principalmente en encontrar agujas en pajares. Para los sistemas LLM, eso ya no es suficiente. Ahora el trabajo también consiste en evitar arrastrar la mitad del pajar al indicador junto con la aguja.
Por eso creo que la idea del BoR es importante y tiene tanto impacto. Proporciona a los profesionales un mejor lenguaje para un problema de producción real: cómo medir cuándo un contexto útil se ha convertido silenciosamente en un contexto contaminado. Y una vez que comienza a mirar sus sistemas de esa manera, muchas fallas familiares de los agentes comienzan a tener mucho más sentido.
BoR no mide directamente lo que el modelo “siente” al leer una indicación, pero sí nos dice cuándo la recuperación deja de ser significativamente selectiva y comienza a parecerse a un relleno de contexto de fuerza bruta. En la práctica, ese es a menudo exactamente el régimen en el que los LLM comienzan a leer más basura, a razonar de manera menos limpia y a desempeñarse peor en el futuro.
En términos más generales, creo que esto apunta a un importante subcampo emergente: desarrollar mejores métricas para medir el desempeño del sistema LLM en entornos realistas, no solo la capacidad del modelo de forma aislada. Nos hemos vuelto razonablemente buenos para medir la precisión, la recuperación y el rendimiento comparativo, pero mucho menos buenos para medir lo que sucede cuando un modelo se ve obligado a razonar a través de un contexto desordenado, superpuesto o débilmente filtrado.
Eso, para mí, expone una brecha real. BoR ayuda a medir la selectividad en relación con el azar, lo cual es valioso. Pero todavía falta un concepto en torno a lo que yo llamaría sobrecarga cognitiva: el punto en el que un modelo aún puede tener la información correcta a la vista, pero funciona peor porque se presentan demasiadas opciones, fragmentos, herramientas o señales en competencia a la vez. En otras palabras, el fracaso ya no es sólo un fracaso de recuperación. Es una falla de razonamiento inducida por una contaminación inmediata.
Sospecho que mejores formas de medir este tipo de sobrecarga cognitiva serán cada vez más importantes a medida que los sistemas agentes se vuelvan más complejos. El próximo salto adelante puede que no provenga sólo de modelos más grandes o ventanas de contexto más grandes, sino de mejores formas de cuantificar cuándo el contexto de trabajo del modelo ha cruzado la línea de una amplitud útil a una sobrecarga dañina.
Inspirado en la publicación de blog/artículo de ICLR 2026, La paradoja del éxito del 99%: cuando la recuperación casi perfecta equivale a selección aleatoria.
Descargo de responsabilidad: Los puntos de vista y opiniones expresados en este artículo son exclusivamente míos y no representan los de mi empleador ni los de ninguna organización afiliada. El contenido se basa en reflexiones personales y pensamientos especulativos sobre el futuro de la ciencia y la tecnología. No debe interpretarse como un consejo profesional, académico o de inversión. Estas perspectivas prospectivas tienen como objetivo suscitar el debate y la imaginación, no hacer predicciones con certeza.