RAG on KnightLi Blog

Qué es PageIndex: un índice documental RAG basado en razonamiento sin bases vectoriales

Wed, 20 May 2026 23:51:37 +0800

VectifyAI/PageIndex es un proyecto RAG interesante. No parte de “crear otra base de datos vectorial”, sino que primero organiza documentos largos en una estructura de árbol similar a una tabla de contenidos, y luego deja que un LLM haga recuperación basada en razonamiento siguiendo ese árbol.

Proyecto: VectifyAI/PageIndex

En el momento de preparar este artículo, la página de GitHub muestra unas 31.8k stars y 2.7k forks, con licencia MIT. El README lo define como Vectorless, Reasoning-based RAG: RAG sin base vectorial y basado en razonamiento.

Qué problema intenta resolver

El flujo común del RAG tradicional es: dividir en chunks, vectorizar, escribir en una base de datos vectorial y recuperar fragmentos mediante búsqueda por similitud. Es un enfoque simple, general y maduro, pero en documentos profesionales largos suele encontrar varios problemas:

La similitud no equivale a relevancia real.
La estructura del documento se rompe por el chunking, y se pierden relaciones entre secciones.
Los resultados de recuperación tienen poca explicabilidad; cuesta explicar por qué se eligió ese fragmento.
En informes financieros, documentos regulatorios, textos legales o manuales técnicos, las preguntas suelen requerir razonamiento entre secciones.

La idea de PageIndex es la inversa: primero organizar el documento como un árbol semántico, y después hacer que el modelo busque como una persona que lee el índice, entra en capítulos y localiza información por niveles.

Flujo básico de PageIndex

El README divide la recuperación de PageIndex en dos pasos:

Generar para el documento un índice en árbol parecido a Table-of-Contents.
Hacer reasoning-based retrieval mediante búsqueda en árbol.

Este árbol no es un simple directorio de archivos, sino una estructura documental pensada para LLMs. Los nodos pueden incluir títulos, rangos de páginas, resúmenes, nodos hijos y otros datos. Así, al responder una pregunta, el modelo no tiene que enfrentarse de entrada a una gran cantidad de chunks sueltos; primero puede decidir a qué sección entrar y luego seguir buscando hacia abajo.

Este enfoque encaja mejor con documentos bien estructurados pero muy largos, como:

Informes financieros y SEC filings.
Material regulatorio y documentos de cumplimiento.
Libros académicos y papers.
Documentos legales.
Manuales técnicos y documentación de producto.
PDFs grandes que superan la ventana de contexto del modelo.

Diferencias con el RAG vectorial tradicional

Los principales puntos de PageIndex se pueden resumir en cinco.

Primero, no necesita Vector DB. Usa estructura documental y razonamiento del LLM para localizar contenido, en lugar de depender solo de búsqueda por similitud vectorial.

Segundo, no usa chunking tradicional. Los documentos se organizan por secciones naturales, no por fragmentos de longitud fija.

Tercero, ofrece mejor explicabilidad. La ruta de recuperación puede asociarse con páginas, secciones y nodos del árbol, lo que es más fácil de rastrear que “este texto fue encontrado por similitud vectorial”.

Cuarto, la recuperación es sensible al contexto. La pregunta, el historial de conversación y el conocimiento del dominio pueden influir en la ruta de búsqueda por árbol.

Quinto, se parece más a cómo los expertos humanos leen documentos. Normalmente no cortamos un documento entero en trozos para calcular similitud; primero revisamos el índice, ubicamos capítulos y luego leemos detalles.

Esto no significa que las bases vectoriales no tengan valor. Una forma más precisa de verlo es que PageIndex encaja en escenarios donde “la similitud semántica no basta y se necesita estructura más razonamiento” para recuperar información en documentos largos.

Cómo ejecutarlo localmente

El README ofrece una ruta de autoalojamiento local. Primero instala dependencias:

`1`	`pip3 install --upgrade -r requirements.txt`

Después crea un archivo .env en la raíz del proyecto y escribe la LLM API key. El proyecto admite múltiples modelos mediante LiteLLM:

`1`	`OPENAI_API_KEY=your_openai_key_here`

Genera la estructura PageIndex para un PDF:

`1`	`python3 run_pageindex.py --pdf_path /path/to/your/document.pdf`

También puede procesar Markdown:

`1`	`python3 run_pageindex.py --md_path /path/to/your/document.md`

Parámetros opcionales habituales:

--model
--toc-check-pages
--max-pages-per-node
--max-tokens-per-node
--if-add-node-id
--if-add-node-summary
--if-add-doc-description

El README también advierte que la versión local de código abierto usa parsing PDF estándar. Para PDFs complejos, el servicio cloud del proyecto ofrece OCR mejorado, construcción de árbol y flujo de recuperación.

Ejemplo de Agentic Vectorless RAG

El proyecto también incluye un ejemplo de agentic vectorless RAG usando PageIndex autoalojado y OpenAI Agents SDK. Instala la dependencia opcional y ejecútalo:

1
2

pip3 install openai-agents
python3 examples/agentic_vectorless_rag_demo.py

El valor de este ejemplo está en que lleva PageIndex de “generar un árbol documental” a “permitir que un Agent use el árbol para recuperar información”. Si estás construyendo una base de conocimiento empresarial, Q&A sobre informes financieros, preguntas regulatorias o un Agent de documentación técnica, vale más la pena correr este ejemplo que limitarse a leer el README.

Servicio cloud, MCP y API

PageIndex no es solo un GitHub repo. La página del proyecto también ofrece varias entradas:

Autoalojamiento: ejecutar el código abierto en local, adecuado para pruebas y despliegues controlados.
Chat Platform: una plataforma de análisis documental estilo ChatGPT.
MCP / API: útil para integrarse con Agents existentes o flujos de automatización.
Enterprise: orientado a despliegues privados u on-premises.

Esto muestra que su posición no es la de una simple demo. Busca convertir la “recuperación documental basada en razonamiento” en una infraestructura de inteligencia documental integrable.

Escenarios adecuados

PageIndex encaja bien con tareas como:

Preguntas y respuestas sobre PDFs largos.
Análisis de informes financieros, informes anuales, prospectos y documentos regulatorios.
Recuperación en documentos legales y de cumplimiento.
Q&A sobre manuales técnicos.
Recuperación en libros o papers con múltiples secciones.
Bases de conocimiento empresariales que necesitan rutas de recuperación explicables.
Proporcionar contexto documental estructurado a Agents.

Si tu material es corto, tiene poca estructura o es simplemente un FAQ común, embedding + vector DB tradicional puede ser suficiente. Las ventajas de PageIndex aparecen con más claridad en documentos largos, estructura fuerte, dominios profesionales y preguntas que requieren razonamiento.

Aspectos a tener en cuenta

Primero, PageIndex sigue dependiendo de LLMs. La construcción del árbol, los resúmenes y la calidad de recuperación se ven afectados por la capacidad del modelo, los prompts y la calidad del parsing documental.

Segundo, la versión local usa parsing PDF estándar. Documentos escaneados complejos, PDFs con muchas tablas y gráficos, o materiales con maquetación desordenada pueden requerir OCR y preprocesamiento más potente.

Tercero, sin base vectorial no significa coste cero. Construir el árbol también consume llamadas al modelo y tiempo, especialmente en colecciones documentales grandes.

Cuarto, PageIndex se parece más a un marco de indexación estructural y recuperación por razonamiento. No reemplaza directamente todas las pilas RAG. En producción, también puede combinarse con recuperación vectorial, búsqueda por palabras clave, control de permisos, caché y sistemas de auditoría.

Resumen

Lo interesante de PageIndex es que desplaza el foco del RAG desde la “recuperación por similitud textual” hacia “estructura documental + razonamiento LLM”. Para documentos largos y profesionales, esta dirección merece atención.

Si estás construyendo Q&A documental empresarial, análisis de informes financieros, recuperación regulatoria o Agents para manuales técnicos, PageIndex puede servir como referencia de una nueva arquitectura RAG: primero dar estructura al documento y luego dejar que el modelo razone sobre esa estructura, en lugar de trocear todo desde el principio y meterlo en una base vectorial.

Referencias:

GitHub: VectifyAI/PageIndex

OpenKB: compilar documentos en una base de conocimiento LLM que se actualiza continuamente

Sun, 17 May 2026 17:15:08 +0800

OpenKB es una herramienta de base de conocimiento LLM de código abierto creada por VectifyAI.

No es un sistema RAG tradicional que divide documentos en fragmentos, los vectoriza y vuelve a ensamblar contexto en cada consulta. OpenKB primero compila los documentos originales en una wiki estructurada: resúmenes de documentos, páginas de conceptos, referencias cruzadas, consultas posteriores y comprobaciones con lint. En otras palabras, se parece más a una CLI de base de conocimiento que organiza materiales de forma continua.

Proyecto: https://github.com/VectifyAI/OpenKB

La idea principal

OpenKB merece atención por tres razones:

Exporta la base de conocimiento como archivos Markdown normales, no como datos encerrados en una base de datos específica.
Usa PageIndex para procesar PDFs largos, con recuperación de documentos largos sin depender de una base vectorial.
Pone el foco en la “compilación de conocimiento”: el LLM genera resúmenes, páginas de conceptos y enlaces cruzados, en vez de buscar desde cero en cada pregunta.

Esto hace que OpenKB encaje bien en escenarios de acumulación de conocimiento a largo plazo: lectura de papers, documentación de proyectos, materiales internos, normas técnicas, investigación de productos y bases de conocimiento personales.

No es un reemplazo universal. Si necesitas Q&A online de alta concurrencia, permisos complejos, panel web de administración, auditoría empresarial o multitenancy a gran escala, OpenKB hoy se parece más a una herramienta para desarrolladores y a un prototipo de base de conocimiento que a una plataforma empresarial completa.

Qué es OpenKB

OpenKB significa Open Knowledge Base.

Funciona como una CLI: convierte, organiza, resume y genera un conjunto de archivos wiki a partir de los documentos añadidos. El README oficial lo explica de forma directa: OpenKB usa LLMs para compilar documentos originales en una base de conocimiento estilo wiki, estructurada e interconectada, con PageIndex para recuperación de documentos largos sin vectores.

Los formatos de entrada soportados incluyen:

PDF
Word
Markdown
PowerPoint
HTML
Excel
Texto plano
Otros formatos convertibles con markitdown

La base de conocimiento generada vive en wiki/ e incluye principalmente:

index.md: visión general de la base de conocimiento
log.md: línea de tiempo de operaciones
AGENTS.md: estructura e instrucciones de mantenimiento
sources/: textos fuente convertidos
summaries/: resúmenes de cada documento
concepts/: páginas de conceptos entre documentos
explorations/: resultados de consultas guardados
reports/: informes de lint

La mayor ventaja de este diseño es la transparencia. Puedes abrir los archivos Markdown directamente, en lugar de recibir respuestas únicamente desde una interfaz de recuperación opaca.

Diferencia con el RAG tradicional

Un flujo RAG tradicional suele ser:

Dividir los documentos en chunks.
Generar embeddings.
Guardarlos en una base vectorial.
Recuperar fragmentos relevantes al consultar.
Pasar esos fragmentos al LLM para generar una respuesta.

Este flujo está maduro y funciona bien para sistemas de preguntas y respuestas. Pero tiene un problema: el conocimiento no se acumula realmente. Cada pregunta vuelve a buscar fragmentos, recomponer contexto y generar una respuesta.

OpenKB sigue más bien la lógica de “organizar primero, preguntar después”:

Los documentos entran en raw/.
Los documentos cortos se convierten a Markdown mediante markitdown.
Los PDFs largos pasan por PageIndex para generar índices en árbol y resúmenes.
El LLM genera resúmenes de documentos.
El LLM lee páginas de conceptos existentes y crea o actualiza conceptos entre documentos.
Se actualizan el índice, el log y los enlaces cruzados de la base de conocimiento.

El resultado es que añadir un documento no solo crea otro archivo recuperable. Puede actualizar una docena de páginas wiki. El conocimiento se escribe en páginas de conceptos y se conecta con materiales existentes.

Esto se parece más a cómo una persona mantiene una base de conocimiento: cuando llega material nuevo, no basta con archivarlo; también hay que actualizar páginas temáticas, resumir diferencias y añadir referencias.

Qué problema resuelve PageIndex

Los documentos largos siempre han sido difíciles para RAG y para las bases de conocimiento con LLM.

Si divides directamente un PDF largo en muchos chunks, aparecen varios problemas:

Se pierden las relaciones entre capítulos.
Tablas, imágenes y notas al pie son difíciles de manejar.
Los fragmentos recuperados son demasiado pequeños y la respuesta pierde estructura global.
Aunque la ventana de contexto sea grande, no conviene meter todo el documento en el prompt.
Las cadenas largas de resumen pueden comprimir y perder detalles importantes.

OpenKB usa PageIndex para procesar PDFs largos. Según la descripción del proyecto, PageIndex crea índices en árbol y resúmenes para documentos largos, de modo que el LLM razona sobre el árbol del documento en lugar de leer todo el documento directamente.

El punto no es encontrar “los párrafos con mayor similitud vectorial”, sino permitir que el modelo use la jerarquía del documento para localizar contenido relevante. Para informes de investigación, papers, manuales, prospectos y documentos de cumplimiento, esta idea tiene mucho sentido.

OpenKB puede usar por defecto la versión open-source de PageIndex de forma local. Si necesitas OCR, procesamiento de PDFs complejos o generación de estructura más rápida, puedes configurar PAGEINDEX_API_KEY para usar PageIndex Cloud.

Instalación e inicio rápido

OpenKB se puede instalar directamente con pip:

`1`	`pip install openkb`

También puedes instalar la versión más reciente desde GitHub:

`1`	`pip install git+https://github.com/VectifyAI/OpenKB.git`

Instalación editable desde el código fuente:

1
2
3

git clone https://github.com/VectifyAI/OpenKB.git
cd OpenKB
pip install -e .

Crea un directorio para la base de conocimiento:

1
2

mkdir my-kb && cd my-kb
openkb init

Añade documentos:

1
2

openkb add paper.pdf
openkb add ~/papers/

Haz una pregunta:

`1`	`openkb query "What are the main findings?"`

Inicia un chat interactivo:

`1`	`openkb chat`

Si quieres que OpenKB procese nuevos archivos automáticamente, usa el modo watch:

`1`	`openkb watch`

Después, coloca archivos en raw/ y OpenKB actualizará la wiki automáticamente.

Configuración del LLM

OpenKB usa LiteLLM para soportar varios proveedores de modelos, incluidos OpenAI, Claude y Gemini.

Puedes establecer el modelo durante la inicialización o configurarlo en .openkb/config.yaml:

1
2
3

model: gpt-5.4
language: en
pageindex_threshold: 20

Los nombres de modelos siguen el formato provider/model de LiteLLM. Los modelos de OpenAI pueden omitir el prefijo del proveedor:

`1`	`model: gpt-5.4`

Modelos como Anthropic y Gemini suelen escribirse así:

`1`	`model: anthropic/claude-sonnet-4-6`

`1`	`model: gemini/gemini-3.1-pro-preview`

La API key va en .env:

`1`	`LLM_API_KEY=your_llm_api_key`

Si activas PageIndex Cloud, añade:

`1`	`PAGEINDEX_API_KEY=your_pageindex_api_key`

Comandos habituales

Los comandos de OpenKB son cómodos para desarrolladores:

openkb init: inicializa una nueva base de conocimiento.
openkb add <file_or_dir>: añade un archivo o directorio.
openkb remove <doc>: elimina un documento y limpia páginas wiki, imágenes, registro y estado de PageIndex relacionados.
openkb query "question": hace una pregunta puntual sobre la base de conocimiento.
openkb chat: entra en una conversación de varios turnos.
openkb watch: vigila raw/ y actualiza automáticamente.
openkb lint: comprueba la estructura y la salud del contenido.
openkb list: lista documentos y conceptos indexados.
openkb status: muestra estadísticas de la base de conocimiento.

openkb chat es más adecuado que openkb query para exploración continua. Soporta reanudar sesiones, listarlas y eliminarlas, y también permite slash commands como /status, /list, /add <path>, /save y /lint.

Por qué importa una wiki Markdown

El problema de muchas herramientas de conocimiento es el coste de migración.

Cuando el material entra en una base de datos, índice o formato propietario, es difícil inspeccionarlo, editarlo, respaldarlo o migrarlo directamente. OpenKB escribe el resultado como Markdown normal, lo que lo hace compatible de forma natural con herramientas existentes.

El uso más directo es abrir wiki/ con Obsidian:

Las páginas de resumen se pueden leer directamente.
Las páginas de conceptos pueden conectarse con [[wikilinks]].
La vista de grafo muestra relaciones entre conocimientos.
Los resultados de consultas pueden guardarse en explorations/.
AGENTS.md puede definir cómo se mantiene la base de conocimiento.

Así OpenKB no es solo una herramienta de Q&A; también puede convertirse en una canalización de organización de conocimiento para personas o equipos.

Escenarios adecuados

OpenKB encaja especialmente bien en:

Lectura de papers e informes técnicos.
Organización de documentación de proyectos.
Archivos de investigación de producto.
Bases de conocimiento documentales alrededor de proyectos open-source.
Organización de normas internas, actas de reuniones y documentos explicativos.
Mantenimiento automático de una base personal en Obsidian.
Estructuración de PDFs largos, PPTs, archivos Word y materiales web.

Si trabajas a menudo con montones de documentos y no solo quieres “hacer una pregunta y obtener una respuesta”, sino convertir esos materiales en una base navegable, reutilizable y trazable, OpenKB va en la dirección correcta.

Aspectos a tener en cuenta

Primero, OpenKB depende de la calidad del LLM.

Resúmenes, páginas de conceptos y enlaces cruzados son generados por el modelo. Cuanto más fuerte sea el modelo, más estable será la compilación de conocimiento; si el modelo es débil, la extracción de conceptos, detección de contradicciones y síntesis entre documentos se resentirán.

Segundo, conviene estimar costes desde el principio.

Si importas muchos documentos largos a la vez, las llamadas al LLM pueden ser caras. Es mejor probar con un conjunto pequeño, verificar estructura y calidad, y luego ampliar.

Tercero, la wiki generada aún necesita revisión humana.

OpenKB puede organizar materiales, pero no garantiza automáticamente que todos los hechos sean correctos. Las bases de conocimiento importantes siguen necesitando revisión humana de resúmenes, conceptos y referencias.

Cuarto, cuidado con materiales sensibles.

Si usas LLMs en la nube o PageIndex Cloud, presta atención a privacidad, secretos comerciales y requisitos de cumplimiento. Para material interno, conviene confirmar primero el proveedor del modelo, la política de retención de datos y los límites de acceso.

Quinto, por ahora es más una herramienta CLI.

El roadmap menciona una futura Web UI, almacenamiento con base de datos, soporte para grandes colecciones e indexación jerárquica de conceptos. En la etapa actual, si el equipo no está cómodo con la línea de comandos, todavía habrá fricción de adopción.

Relación con Obsidian, NotebookLM y RAG empresarial

La relación entre OpenKB y Obsidian se entiende mejor como una “capa de organización automática” más una “capa de lectura y edición”.

Obsidian es bueno para que las personas escriban, editen, naveguen y creen enlaces. OpenKB es bueno para convertir documentos originales en una wiki que pueda entrar en Obsidian.

OpenKB y NotebookLM se diferencian más por control local y formato abierto.

NotebookLM ofrece una experiencia más directa para cargar materiales, preguntar y generar resúmenes rápidamente. OpenKB encaja mejor cuando un desarrollador quiere dejar el resultado organizado en un directorio local y seguir manteniéndolo como Markdown.

OpenKB no sustituye al RAG empresarial; lo complementa.

El RAG empresarial prioriza permisos, auditoría, despliegue como servicio, aislamiento de acceso, monitoreo y throughput estable. OpenKB sirve mejor para construir una capa de conocimiento legible, editable y acumulable. Si más adelante construyes Q&A online, la wiki generada por OpenKB también puede ser un corpus de mayor calidad.

Un flujo recomendado

Si quieres probar OpenKB, puedes empezar así:

Crea un directorio de prueba para la base de conocimiento.
Añade de 3 a 5 documentos sobre el mismo tema.
Ejecuta openkb add.
Abre wiki/ y revisa resúmenes y páginas de conceptos.
Haz algunas preguntas concretas con openkb query.
Ejecuta openkb lint para revisar la salud de la base.
Abre wiki/ en Obsidian y mira si el grafo de enlaces tiene sentido.
Cuando la calidad sea aceptable, importa una colección más grande.

No metas cientos de archivos desde el principio. Primero comprueba si entiende bien tu tipo de material, especialmente tablas, imágenes, PDFs largos y fusión de conceptos entre documentos.

Resumen

El valor de OpenKB está en adelantar un paso el flujo de una base de conocimiento LLM: en vez de armar contexto temporalmente al consultar, primero organiza los materiales como wiki y luego permite preguntar, chatear, revisar y seguir manteniendo esa wiki.

Esta ruta no sirve para todos los sistemas de Q&A, pero sí para trabajo de conocimiento que necesita acumulación a largo plazo. Archivos Markdown, compatibilidad con Obsidian, manejo de documentos largos con PageIndex, soporte multi-modelo y flujo CLI forman una herramienta útil para desarrolladores y usuarios orientados a investigación.

Si tienes muchos PDFs, informes, páginas web, papers y documentos de proyecto, vale la pena probar OpenKB. Quizá no reemplace de inmediato una base de conocimiento empresarial madura, pero puede ser una entrada práctica para organizar materiales: primero convierte documentos en conocimiento legible, enlazado y trazable, y luego deja que el LLM trabaje sobre esa base.

Referencias:

Términos de informática en lenguaje simple: qué significan TTS, STT, API, RAG y Agent

Tue, 12 May 2026 22:15:34 +0800

En informática hay muchos términos que, al escucharlos por primera vez, parecen muy avanzados. Pero cuando se traducen a lenguaje simple, a menudo describen acciones cotidianas.

Por ejemplo, cuando una IA puede hablar, se llama TTS; cuando puede escucharte, se llama STT. Suena como un sistema complejo, pero separado en partes es simplemente “leer texto en voz alta” y “transcribir voz a texto”.

Enlace de referencia: https://www.zhihu.com/question/267978646/answer/2035405228460201515

Este artículo recorre varios términos comunes desde ese ángulo: conservar los términos, pero explicarlos en palabras simples.

TTS y STT: convertir entre texto y voz

TTS significa Text-to-Speech, es decir, convertir texto en voz. Escribes un texto y el sistema lo convierte en audio reproducible. La navegación por voz, la lectura de libros electrónicos, los bots de atención al cliente y los asistentes de voz usan esta capacidad.

STT significa Speech-to-Text, es decir, convertir voz en texto. Cuando le hablas al móvil, el sistema primero reconoce la voz como texto y luego entrega ese texto al programa siguiente. Dictado por voz, transcripción de reuniones, subtítulos automáticos y altavoces inteligentes dependen de STT.

Muchos productos de IA por voz funcionan así:

STT: convierte lo que dijiste en texto.
LLM: genera una respuesta a partir del texto.
TTS: lee la respuesta en voz alta.

Por eso parece una conversación natural, aunque por debajo varios módulos se pasan el trabajo.

OCR: copiar texto desde imágenes

OCR significa Optical Character Recognition.

En lenguaje simple, consiste en sacar texto de una imagen. Fotografiar una factura, escanear una página de un libro o leer el nombre y número de un documento de identidad son tareas de OCR.

Antes, OCR se parecía más a “adivinar la forma de los caracteres”. Hoy usa deep learning y tolera mejor fondos complejos, texto inclinado, escritura manual e imágenes borrosas. Pero la pregunta central sigue siendo directa: ¿qué texto hay en la imagen?

NLP y LLM: hacer que las máquinas procesen lenguaje humano

NLP significa Natural Language Processing. Trata con lenguaje humano: tokenización, traducción, resumen, análisis de sentimiento, preguntas y respuestas, clasificación.

LLM significa Large Language Model. Puede entender y generar texto, así que hoy muchas tareas de NLP las realizan LLMs.

Versión simple:

NLP: hacer que las máquinas procesen lo que las personas dicen y escriben.
LLM: un modelo de texto grande capaz de manejar muchas tareas de lenguaje.

Cuando pides a una IA resumir un artículo, escribir un correo, mejorar un título o explicar código, estás en este campo general.

API y SDK: una es una interfaz, el otro es un kit

API significa Application Programming Interface.

En lenguaje simple, alguien abre una entrada para que puedas llamar una capacidad. Una API del clima recibe una ciudad y devuelve el tiempo; una API de pagos recibe un pedido y devuelve el resultado del pago.

SDK significa Software Development Kit.

En lenguaje simple, el equipo oficial empaqueta código común, tipos, ejemplos y herramientas para que llames la API más fácilmente. Una API es como el mostrador de un restaurante; un SDK es como una app para pedir. Puedes hablar directamente con el mostrador o usar la app para hacerlo con menos fricción.

CRUD: crear, leer, actualizar y borrar

CRUD significa Create, Read, Update, Delete.

En lenguaje simple: añadir, ver, modificar y eliminar.

Muchos sistemas administrativos, paneles de gestión y operaciones de base de datos giran alrededor de CRUD. Gestión de usuarios, artículos, pedidos o inventario parecen negocios distintos, pero por debajo suelen ser formularios más crear/leer/actualizar/borrar.

Por eso los programadores dicen “otra vez CRUD”. No necesariamente lo dicen con desprecio; simplemente aparece en todas partes.

Cache: guardar una copia para no recalcular cada vez

Cache significa caché.

En lenguaje simple, dejar cerca lo que se usa con frecuencia para tomarlo directamente la próxima vez, sin buscarlo, calcularlo o pedirlo de nuevo.

Una página web puede cachear imágenes y scripts; una consulta lenta puede guardar resultados populares en Redis; una inferencia cara de modelo puede cachear respuestas a preguntas repetidas.

La parte difícil de la caché no es “guardar una copia”, sino “saber cuándo actualizarla”. Si los datos cambian y la caché no, aparece información antigua. Ese es el origen de muchos problemas de caché.

Queue: poner tareas en fila y procesarlas poco a poco

Queue significa cola.

En lenguaje simple: hay demasiadas cosas por hacer, así que se ponen en fila y se procesan una por una.

Por ejemplo, cuando un usuario sube un video, la transcodificación no siempre termina de inmediato. El sistema puede poner la tarea en una cola y dejar que un servicio en segundo plano la procese. Enviar SMS, correos, generar informes y manejar callbacks de pedidos también suele usar colas.

Las colas evitan que todas las tareas lentas bloqueen la petición actual. El usuario recibe respuesta primero y el trabajo pesado ocurre después.

Index: una tabla de contenidos para la base de datos

Index significa índice.

Un índice de base de datos es como el índice de un libro. Sin índice, quizá tengas que leer desde la primera página hasta la última; con índice, llegas más rápido al contenido.

Pero no siempre conviene tener más índices. Las consultas pueden ser más rápidas, pero las escrituras y actualizaciones pueden volverse más lentas, porque el índice también debe mantenerse cuando cambian los datos.

Por eso en optimización de bases de datos se suele mirar primero el índice de una consulta lenta. Pero al crear uno hay que considerar condiciones de búsqueda, campos de orden, volumen de datos y frecuencia de escritura.

RPC, REST y Webhook: cómo hablan los sistemas

RPC significa Remote Procedure Call.

En lenguaje simple, es llamar una función que vive en otra máquina como si fuera una función local.

REST es común en Web API. Usa URLs y métodos HTTP para expresar operaciones sobre recursos, por ejemplo GET /users para consultar usuarios y POST /orders para crear pedidos.

Webhook es una notificación en sentido contrario. En vez de preguntar todo el tiempo “¿ya está?”, el otro sistema llama tu URL cuando ocurre algo.

Forma simple de recordarlo:

RPC: llamar una función remota.
REST: gestionar recursos con HTTP.
Webhook: recibir aviso cuando algo sucede.

CDN y Load Balancing: acercar contenido y repartir carga

CDN significa Content Delivery Network.

En lenguaje simple, colocar recursos estáticos en nodos más cercanos al usuario. Al acceder a imágenes, videos, CSS o JS, no siempre hace falta ir al servidor de origen.

Load Balancing significa balanceo de carga.

En lenguaje simple, si hay demasiado tráfico, no obligar a un solo servidor a cargar con todo; repartir las peticiones entre varias máquinas.

Uno trata de estar más cerca del usuario; el otro evita agotar una máquina. Los sitios grandes suelen usar ambos.

Docker, Container y Kubernetes: empaquetar, ejecutar y orquestar

Docker es una herramienta común de contenedores, y Container significa contenedor.

En lenguaje simple, empaquetar el programa junto con el entorno que necesita para que pueda ejecutarse de forma similar en otra máquina. Así se reduce el problema de “en mi ordenador funciona, en el servidor no”.

Kubernetes, a menudo escrito K8s, es un sistema de orquestación de contenedores.

En lenguaje simple, cuando hay muchos contenedores, decide dónde corren, cómo reiniciarlos si fallan, cómo repartir tráfico y cómo actualizar versiones.

Si solo tienes un servicio pequeño, Docker puede bastar. Si tienes muchos servicios, máquinas y réplicas, K8s empieza a tener más sentido.

CI/CD: construir y desplegar automáticamente

CI significa Continuous Integration.

En lenguaje simple, cuando se envía código, el sistema lo descarga, ejecuta pruebas y lo construye automáticamente para detectar problemas pronto.

CD puede significar Continuous Delivery o Continuous Deployment.

En lenguaje simple, cuando la build pasa, el código se envía de forma más estable y automática a pruebas o producción.

No resuelve “cómo escribir código”, sino “cómo publicar lo escrito con menos errores”.

Serialization: empaquetar objetos en un formato transmisible

Serialization significa serialización.

En lenguaje simple, convertir objetos del programa en un formato que se pueda guardar o transmitir, como JSON, XML o Protobuf.

Lo contrario, Deserialization, convierte esos formatos de vuelta en objetos que el programa puede usar.

Cuando frontend y backend intercambian JSON, o dos servicios usan Protobuf, hay serialización de por medio.

Token, Embedding y Vector DB: convertir texto en formas que el modelo puede procesar

En modelos grandes, Token suele ser la unidad básica en la que se divide el texto. No siempre equivale a un carácter chino o a una palabra inglesa; es más bien la granularidad interna con la que el modelo procesa texto.

Embedding significa vector de incrustación.

En lenguaje simple, convierte texto, imágenes u otros contenidos en una secuencia de números para que el modelo pueda comparar similitudes.

Vector DB significa base de datos vectorial.

En lenguaje simple, guarda esos vectores y permite encontrar rápido contenido con significado parecido.

Por ejemplo, si preguntas “cómo resetear el router”, el sistema puede buscar en la base vectorial contenidos como “restaurar configuración de fábrica”, “olvidé la contraseña Wi-Fi” o “fallo al entrar al panel”, y pasarlos al modelo como referencia.

RAG: buscar primero, responder después

RAG significa Retrieval-Augmented Generation.

En lenguaje simple, antes de responder, el modelo busca información relevante en una base de conocimiento y luego responde usando esos materiales.

Esto reduce el problema de que los modelos grandes inventen cosas desde la memoria. Al conectar documentos internos, bases de conocimiento, manuales de producto o fragmentos de código, el modelo puede usar materiales actuales proporcionados por ti.

Un flujo típico es:

El usuario hace una pregunta.
El sistema convierte la pregunta en un Embedding.
Busca documentos relacionados en una Vector DB.
Envía fragmentos de documentos y la pregunta a un LLM.
El modelo genera la respuesta.

Así que RAG suena avanzado, pero en esencia es: primero consulta materiales, luego organiza la respuesta.

Agent: un flujo automatizado que descompone tareas

En el contexto de IA, Agent suele traducirse como agente inteligente.

En lenguaje simple, no solo responde una frase; puede dividir un objetivo en pasos, llamar herramientas, observar resultados y decidir la siguiente acción.

Por ejemplo, si le pides “analiza por qué fallan las pruebas en este repositorio”, un modelo de chat común quizá solo dé consejos. Un Agent puede leer archivos, ejecutar pruebas, revisar errores, modificar código y volver a ejecutar pruebas.

Por supuesto, Agent no significa fiabilidad garantizada. Es básicamente “modelo + llamadas a herramientas + bucle de estado”. Que funcione bien depende de permisos, límites de la tarea, manejo de errores y confirmación humana.

Resumen

Muchos términos informáticos parecen avanzados porque vienen envueltos en siglas, diagramas de arquitectura y marketing de producto. Al desmontarlos, muchos describen acciones muy simples:

TTS: leer texto en voz alta.
STT: transcribir voz.
OCR: copiar texto desde imágenes.
API: abrir una entrada de llamada.
SDK: empaquetar herramientas de llamada.
CRUD: crear, leer, actualizar y borrar.
Cache: guardar una copia de resultados comunes.
Queue: poner tareas en fila para procesarlas después.
Index: poner una tabla de contenidos a los datos.
CDN: acercar contenido al usuario.
Load Balancing: repartir peticiones.
Docker: empaquetar el entorno de ejecución.
CI/CD: automatizar pruebas y despliegue.
Embedding: convertir contenido en vectores numéricos.
RAG: buscar primero, responder después.
Agent: dejar que el modelo use herramientas paso a paso.

Conviene conservar los términos porque ayudan a buscar, comunicarse y leer documentación. Pero no hace falta dejarse intimidar. Primero tradúcelos a lenguaje simple; luego vuelve a los detalles técnicos. Muchos conceptos se vuelven mucho más claros.

Referencia

Respuesta de Zhihu: https://www.zhihu.com/question/267978646/answer/2035405228460201515

Gemini Embedding 2: texto, imagen, video y audio en un mismo espacio vectorial

Mon, 04 May 2026 06:01:10 +0800

Google Developers Blog presento el uso de Gemini Embedding 2 para desarrollo. El modelo ya esta en GA a traves de Gemini API y Gemini Enterprise Agent Platform. Lo importante no es solo que sea “un nuevo modelo de embedding”, sino que puede mapear texto, imagenes, video, audio y documentos al mismo espacio semantico.

Esto amplia los limites de los sistemas de recuperacion. Antes, muchos flujos RAG necesitaban convertir imagenes, videos o audio en texto o metadatos y crear indices separados. Gemini Embedding 2 puede procesar directamente entradas multimodales, haciendo que agents, busqueda y sistemas de clasificacion trabajen mas facilmente con materiales reales de negocio.

Enlace original: Building with Gemini Embedding 2: Agentic multimodal RAG and beyond

Capacidades del modelo

Gemini Embedding 2 admite mas de 100 idiomas. Una sola solicitud puede procesar:

Hasta 8,192 tokens de texto.
Hasta 6 imagenes.
Hasta 120 segundos de video.
Hasta 180 segundos de audio.
Hasta 6 paginas PDF.

La clave es el “espacio semantico unificado”. Los desarrolladores pueden poner contenidos de distintas modalidades en una misma representacion vectorial y aplicar la misma logica de recuperacion, clustering o reranking.

Por ejemplo, una descripcion de texto y una imagen pueden ir en la misma solicitud de embedding:

from google import genai
from google.genai import types

client = genai.Client()

with open('dog.png', 'rb') as f:
    image_bytes = f.read()
result = client.models.embed_content(
    model='gemini-embedding-2',
    contents=[
        "An image of a dog",
        types.Part.from_bytes(
            data=image_bytes,
            mime_type='image/png',
        ),
    ]
)

print(result.embeddings)

Si quieres obtener un embedding separado para cada entrada, en vez de agregarlas en un unico vector, puedes usar Batch API. El articulo tambien menciona que Agent Platform sigue avanzando en este soporte por lotes.

Que significa para RAG

El embedding multimodal es muy util para RAG agentico. Un AI agent puede necesitar revisar al mismo tiempo repositorios de codigo, PDF, capturas, graficos, transcripciones de reuniones y fotos de producto. Si todos los materiales entran en el mismo espacio semantico, la recuperacion no necesita una entrada distinta para cada formato.

Google recomienda usar task prefix segun la tarea para acercar el embedding al objetivo de recuperacion. Por ejemplo, preguntas y respuestas, fact checking, recuperacion de codigo y resultados de busqueda pueden usar prefijos distintos:

# Generate embedding for your task's query:
def prepare_query(query):
    return f"task: question answering | query: {content}"
    # return f"task: fact checking | query: {content}"
    # return f"task: code retrieval | query: {content}"
    # return f"task: search result | query: {content}"
# Generate embedding for document of an asymmetric retrieval task:
def prepare_document(content, title=None):
    if title is None:
        title = "none"
    return f"title: {title} | text: {content}"

Este prefijo encaja con recuperacion asimetrica: las consultas suelen ser cortas y los documentos largos. Preparar query y document con formatos de tarea distintos puede mejorar el emparejamiento entre consulta corta y documento largo.

El articulo da dos resultados reales:

Harvey mejoro un 3% el Recall@20 precision frente a la generacion anterior de embedding en benchmarks legales.
Supermemory mejoro un 40% el Recall@1 en precision de busqueda y lo usa en memoria, indexacion, busqueda y Q&A.

Estos numeros no significan que todos los escenarios mejoren igual, pero muestran que el embedding multimodal ya no es solo una demostracion, sino que produce efecto en productos reales de busqueda.

Busqueda visual

Gemini Embedding 2 tambien encaja con busqueda por imagen, busqueda mixta imagen-texto e identificacion de productos. El articulo menciona que Nuuly, una empresa de alquiler de ropa, lo uso para emparejar fotos de ropa sin etiquetar en almacen: Match@20 subio de 60% a casi 87%, y el exito total de identificacion paso de 74% a mas de 90%.

La clave de estos escenarios no es generar contenido, sino entender “a que inventario, documento o registro de producto se parece mas esta imagen”. Si tu negocio tiene muchas imagenes, clips de video o documentos escaneados, el embedding multimodal es mas natural que un indice puramente textual.

Reranking de recuperacion

El embedding tambien puede usarse para rerank. Una practica comun es recuperar primero un grupo de candidatos y luego calcular la similitud entre cada candidato y la consulta del usuario, subiendo los resultados mas relevantes:

# 1. Define a function to calculate the dot product (cosine similarity)
def dot_product(a: np.ndarray, b: np.ndarray):
  return (np.array(a) @ np.array(b).T)
# 2. Retrieve your embeddings
# (Assuming 'summaries' is your list of search results)
search_res = get_embeddings(summaries)
embedded_query = get_embeddings([query])

# 3. Calculate similarity scores
sim_value = dot_product(search_res, embedded_query)

# 4. Select the most relevant result
best_match_index = np.argmax(sim_value)

El articulo tambien menciona otra idea: pedir primero al modelo que genere una respuesta hipotetica con su conocimiento interno, hacer embedding de esa respuesta y compararla con los candidatos. Esto ayuda a elegir resultados semanticamente mas cercanos, especialmente en RAG de preguntas y respuestas.

Clustering, clasificacion y deteccion de anomalias

Ademas de recuperacion, los embeddings sirven para clustering, clasificacion y deteccion de anomalias. A diferencia de la recuperacion de preguntas y respuestas, estas son tareas simetricas: query y document pueden usar el mismo prefijo de tarea.

# Generate embedding for query & document of your task.
def prepare_query_and_document(content):
    # return f'task: clustering | query: {content}'
    # return f'task: sentence similarity | query: {content}'
    # return f'task: classification | query: {content}'

Estas tareas pueden aplicarse a clasificacion de opinion publica, moderacion de contenido, agrupacion de activos similares y deteccion de muestras anomalas. Tambien pueden ayudar a un agent a ordenar mucho contexto antes de entrar en razonamiento posterior.

Almacenamiento y coste

Gemini Embedding 2 devuelve por defecto vectores de 3,072 dimensiones. Usa Matryoshka Representation Learning, por lo que puedes truncar el vector a una dimension menor con output_dimensionality. Google recomienda 1,536 o 768 dimensiones cuando la eficiencia es prioritaria:

result = client.models.embed_content(
    model="gemini-embedding-2",
    contents="What is the meaning of life?",
    config={"output_dimensionality": 768}
)

Los vectores pueden almacenarse en Agent Platform Vector Search, Pinecone, Weaviate, Qdrant, ChromaDB y sistemas similares. En coste, el articulo menciona que Batch API ofrece mayor throughput y puede llegar al 50% del precio por defecto de embeddings.

Como usarlo como desarrollador

Si ya tienes RAG textual, puedes empezar con dos mejoras incrementales:

Poner PDF, capturas, descripciones de imagen y documentos de texto en un mismo indice, y comprobar si la recuperacion se vuelve mas estable.
Agregar task prefix para distintas tareas, como Q&A, fact checking, recuperacion de codigo y busqueda de productos. No proceses todo con el mismo formato de embedding.

Si estas creando un producto nuevo, considera primero estas direcciones:

Base de conocimiento empresarial: recuperar documentos, graficos, capturas de presentaciones y material de reuniones al mismo tiempo.
Busqueda visual: encontrar productos, activos, disenos y archivos usando imagen, texto o entradas mixtas.
Toolchain de Agent: permitir que coding agents, research agents o agentes de soporte recuperen materiales de negocio en varios formatos.
Gobernanza de contenido: clasificar, agrupar y detectar anomalias en texto, imagenes y clips de video.

El valor de Gemini Embedding 2 esta en convertir materiales multimodales en un mismo conjunto de activos recuperables. Para desarrolladores, reduce la capa intermedia de “convertir primero a texto y luego buscar”, y acerca los sistemas RAG a la forma real de los datos del mundo.

Cómo Elegir Modelos de Embedding Comunes: OpenAI vs BGE vs E5 vs GTE vs Jina

Thu, 23 Apr 2026 15:23:47 +0800

Cuando las personas comienzan a construir sistemas RAG, búsqueda semántica o recuperación de bases de conocimiento, a menudo se quedan atascadas en la misma pregunta: hay tantos modelos de embedding, ¿así que cuál debe elegir?

Las opciones comunes se pueden dividir aproximadamente en dos grupos. Un grupo son los embeddings de texto de propósito general que cubren tareas en chino, inglés y multilingües. El otro grupo está mejor adaptado a escenarios en chino, especialmente la recuperación en chino, el QA en chino y las bases de conocimiento en chino.

Si quieres la versión corta primero, esta es una forma práctica de verlo:

Si quieres el camino más fácil y prefieres usar una API directamente: text-embedding-3-small o text-embedding-3-large
Si quieres recuperación en chino y prefieres modelos de código abierto que puedes autoalojar: bge-base-zh-v1.5, bge-m3, gte-large-zh
Si necesitas soporte multilingüe: multilingual-e5-base, multilingual-e5-large, jina-embeddings-v3
Si quieres mantener bajos los costos en escenarios chinos: bge-small-zh-v1.5, gte-base-zh

1. Primero, Míralos por Categoría

1. Serie OpenAI

text-embedding-3-small
text-embedding-3-large

Las principales fortalezas de estos modelos son la simplicidad y la estabilidad. Son adecuados si quieres llamar a una API directamente para recuperación, RAG, clasificación y coincidencia de similitud. Su ventaja no es que dominen una tabla de clasificación china específica, sino que la experiencia general es completa: bajo costo de integración, calidad estable y baja sobrecarga de ingeniería.

Si tu equipo no quiere alojar modelos ni mantener servicios de inferencia, OpenAI suele ser la opción que ahorra más tiempo.

2. Serie BGE

BAAI/bge-small-zh-v1.5
BAAI/bge-base-zh-v1.5
bge-m3

BGE es una de las familias más comunes utilizadas en recuperación china. bge-small-zh-v1.5 y bge-base-zh-v1.5 se inclinan más hacia tareas monolingües en chino, lo que los hace adecuados para la búsqueda semántica en chino, la recuperación de bases de conocimiento y la coincidencia de preguntas frecuentes (FAQ). bge-m3 es más de propósito general y puede cubrir escenarios de recuperación multilingües, de multi-granularidad y más complejos.

Si la mayor parte de tus datos es texto en chino, BGE es a menudo una de las familias más fáciles de incluir en la lista corta.

3. Serie E5

intfloat/multilingual-e5-base
multilingual-e5-large

La fortaleza de la familia E5 es una capacidad multilingüe más equilibrada. Funciona bien para datos mixtos chinos-inglés, recuperación translingüística y bibliotecas de contenido internacionalizado. No se enfoca solo en chino.

4. Serie E5

5. Serie E5

6. Serie E5

7. Serie E5

8. Serie E5

9. Serie E5

10. Serie E5

11. Serie E5

12. Serie E5

13. Serie E5

14. Serie E5

15. Serie E5

16. Serie E5

17. Serie E5

18. Serie E5

19. Serie E5

20. Serie E5

21. Serie E5

22. Serie E5

23. Serie E5

24. Serie E5

25. Serie E5

26. Serie E5

27. Serie E5

28. Serie E5

29. Serie E5

30. Serie E5

31. Serie E5

32. Serie E5

33. Serie E5

34. Serie E5

35. Serie E5

36. Serie E5

37. Serie E5

38. Serie E5

39. Serie E5

40. Serie E5

41. Serie E5

42. Serie E5

43. Serie E5

44. Serie E5

45. Serie E5

46. Serie E5

47. Serie E5

48. Serie E5

49. Serie E5

50. Serie E5

51. Serie E5

52. Serie E5

53. Serie E5

54. Serie E5

55. Serie E5

56. Serie E5

57. Serie E5

58. Serie E5

59. Serie E5

60. Serie E5

61. Serie E5

62. Serie E5

63. Serie E5

64. Serie E5

65. Serie E5

66. Serie E5

67. Serie E5

68. Serie E5

69. Serie E5

70. Serie E5

71. Serie E5

72. Serie E5

73. Serie E5

74. Serie E5

75. Serie E5

76. Serie E5

77. Serie E5

78. Serie E5

79. Serie E5

80. Serie E5

81. Serie E5

82. Serie E5

83. Serie E5

84. Serie E5

85. Serie E5

86. Serie E5

87. Serie E5

88. Serie E5

89. Serie E5

90. Serie E5

91. Serie E5

92. Serie E5

93. Serie E5

94. Serie E5

95. Serie E5

96. Serie E5

97. Serie E5

98. Serie E5

99. Serie E5

100. Serie E5

101. Serie E5

102. Serie E5

103. Serie E5

104. Serie E5

105. Serie E5

106. Serie E5

107. Serie E5

108. Serie E5

109. Serie E5

110. Serie E5

111. Serie E5

112. Serie E5

113. Serie E5

114. Serie E5

115. Serie E5

116. Serie E5

117. Serie E5

118. Serie E5

119. Serie E5

120. Serie E5

121. Serie E5

122. Serie E5

123. Serie E5

124. Serie E5

125. Serie E5

126. Serie E5

127. Serie E5

128. Serie E5

129. Serie E5

130. Serie E5

131. Serie E5

132. Serie E5

133. Serie E5

134. Serie E5

135. Serie E5

136. Serie E5

137. Serie E5

138. Serie E5

139. Serie E5

140. Serie E5

141. Serie E5

142. Serie E5

143. Serie E5

144. Serie E5

145. Serie E5

146. Serie E5

147. Serie E5

148. Serie E5

149. Serie E5

150. Serie E5

151. Serie E5

152. Serie E5

153. Serie E5

154. Serie E5

155. Serie E5

156. Serie E5

157. Serie E5

158. Serie E5

159. Serie E5

160. Serie E5

161. Serie E5

162. Serie E5

163. Serie E5

164. Serie E5

165. Serie E5

166. Serie E5

167. Serie E5

168. Serie E5

169. Serie E5

170. Serie E5

171. Serie E5

172. Serie E5

173. Serie E5

174. Serie E5

175. Serie E5

176. Serie E5

177. Serie E5

178. Serie E5

179. Serie E5

180. Serie E5

181. Serie E5

182. Serie E5

183. Serie E5

184. Serie E5

185. Serie E5

186. Serie E5

187. Serie E5

188. Serie E5

189. Serie E5

190. Serie E5

191. Serie E5

192. Serie E5

193. Serie E5

194. Serie E5

195. Serie E5

196. Serie E5

197. Serie E5

198. Serie E5

199. Serie E5

200. Serie E5

201. Serie E5

202. Serie E5

203. Serie E5

204. Serie E5

205. Serie E5

206. Serie E5

207. Serie E5

208. Serie E5

209. Serie E5

210. Serie E5

211. Serie E5

212. Serie E5

213. Serie E5

214. Serie E5

215. Serie E5

216. Serie E5

217. Serie E5

218. Serie E5

219. Serie E5

220. Serie E5

221. Serie E5

222. Serie E5

223. Serie E5

224. Serie E5

225. Serie E5

226. Serie E5

227. Serie E5

228. Serie E5

229. Serie E5

230. Serie E5

231. Serie E5

232. Serie E5

233. Serie E5

234. Serie E5

235. Serie E5

236. Serie E5

237. Serie E5

238. Serie E5

239. Serie E5

240. Serie E5

241. Serie E5

242. Serie E5

243. Serie E5

244. Serie E5

245. Serie E5

246. Serie E5

247. Serie E5

248. Serie E5

249. Serie E5

250. Serie E5

Términos de AI explicados: Agent, MCP, RAG y Token en lenguaje simple

Thu, 23 Apr 2026 13:13:40 +0800

Cuando la gente empieza con AI, lo que suele alejarla no son los modelos en sí, sino la larga lista de términos que aparecen en cada discusión. Agent, MCP, RAG, AIGC y Token suenan familiares, pero sin una explicación simple muchas personas solo reconocen las palabras sin entenderlas de verdad.

Este artículo condensa 10 términos frecuentes de AI en significados más fáciles de recordar. El objetivo no es sonar académico, sino ayudarte a construir un modelo mental básico para seguir conversaciones cotidianas sobre AI.

10 términos comunes de AI y qué significan

1. Agent: una AI que hace más que chatear

Agent puede entenderse como un asistente AI que realmente hace trabajo.

Un chatbot normal suele seguir un patrón de pregunta y respuesta. Un Agent va más lejos: puede dividir una tarea en pasos, organizar un proceso, llamar herramientas y devolver un resultado terminado. Si le pides organizar materiales, buscar algo o generar un documento, quizá no solo dé consejos, sino que encadene acciones y las complete.

Por eso el punto clave de un Agent no es si puede hablar, sino si puede actuar.

2. OpenClaw: un asistente AI que vive en tu ordenador

Aquí, OpenClaw se describe como un tipo de asistente AI que vive en tu ordenador.

Puedes pensar en esta herramienta como un ayudante AI más orientado al escritorio. No solo recibe texto. También puede observar la interfaz, llamar herramientas locales y ejecutar tareas paso a paso. Frente a un chat web normal, enfatiza mucho más la capacidad operativa.

Si Agent es la idea abstracta de una AI orientada a ejecución, este tipo de asistente de escritorio es una versión concreta para ordenador personal.

3. Skills: paquetes de capacidad añadidos a un Agent

Skills pueden entenderse como módulos funcionales o instrucciones operativas para un Agent.

El mismo Agent puede comportarse muy distinto según las Skills que tenga. Algunas se centran en copywriting, otras en organizar datos y otras en código. Son un poco como apps en un teléfono y un poco como workflows reutilizables.

En muchos casos no es que el modelo se vuelva más inteligente de repente. Es que se añadieron reglas, herramientas y pasos más claros detrás.

4. MCP: una forma unificada para conectar AI con herramientas

MCP significa Model Context Protocol.

En términos cotidianos, es un poco como un conector Type-C para el mundo AI. Antes, conectar un modelo a distintas herramientas solía exigir integraciones separadas una por una. Con un protocolo unificado, la forma de conectar herramientas se vuelve más estándar y reutilizable.

Para la mayoría de usuarios, lo importante es recordar esto: MCP no trata de si un modelo puede responder una pregunta. Trata de cómo un modelo puede conectarse a herramientas y recursos externos de forma segura y estable.

5. Gacha: la salida AI es inherentemente aleatoria

El término “gacha” aparece a menudo en generación de imágenes, video y trabajo creativo con AI.

La idea es simple. Incluso con el mismo prompt y la misma dirección general, el resultado puede cambiar cada vez. A veces sale genial. A veces se rompe. Por eso se compara repetir generaciones con tirar gacha en un juego.

Esto recuerda que la generación AI no es una fórmula fija, sino un proceso probabilístico con variación.

6. API: la conexión entre una app y un modelo

API significa Application Programming Interface.

Puedes pensarla como el punto de entrada estándar por el que los programas se comunican. Cuando llamas un servicio de modelo desde tu app, script o editor, usas una API para enviar una solicitud y recibir un resultado.

Si comparas un servicio de modelo con un restaurante:

el menú es como la documentación de API
hacer un pedido es como una solicitud API
la cocina devolviendo el plato es como el modelo devolviendo resultado

Por eso muchas herramientas pueden verse distintas en superficie y aun así llamar alguna API por debajo.

7. Multimodalidad: AI maneja más que texto

Multimodality significa que AI ya no solo lee y escribe texto. Puede procesar varios tipos de entrada y salida.

Por ejemplo, puede leer imágenes, entender voz, interpretar video, generar dibujos o soportar interacción de voz y video en tiempo real. Frente a los primeros modelos solo texto, los modelos multimodales se acercan más a combinar ver, oír, hablar y escribir.

Por eso muchos productos AI ya no giran alrededor de una sola caja de texto.

8. RAG: recuperar información primero y luego generar respuesta

RAG significa Retrieval-Augmented Generation.

Sirve para resolver un problema práctico: los datos de entrenamiento de un modelo tienen un límite temporal y no conoce automáticamente los documentos nuevos de tu empresa, registros de soporte o reglas de negocio. La idea de RAG es recuperar primero material relevante de fuentes específicas y luego generar una respuesta basada en ese material.

Su valor aparece en tres formas:

las respuestas se mantienen más cerca del material fuente real
puedes rastrear de dónde salió la respuesta
documentos nuevos pueden añadirse y reflejarse rápido

Por eso muchas bases de conocimiento empresariales, sistemas de atención AI y herramientas internas de Q&A dependen de RAG.

9. AIGC: término general para contenido generado por AI

AIGC significa AI Generated Content.

No es una herramienta concreta. Es una etiqueta amplia para contenido producido por AI: texto, imágenes, audio, video y más. Escritura AI, ilustración AI, generación de video corto y síntesis de voz AI entran bajo AIGC.

Lo importante es que describe una forma de producir contenido, no un modelo específico.

10. Token: la unidad usada para medir procesamiento del modelo

Token puede entenderse como la unidad básica que un modelo usa para procesar texto.

No equivale exactamente a un carácter o una palabra, pero en la práctica puedes tratarlo como la unidad común para cómputo y facturación del modelo. Tu entrada consume Token, la salida del modelo consume Token y el contexto guardado en memoria también ocupa Token.

Por eso los servicios de modelos hablan tanto de longitud de contexto, control de coste y compresión de prompts. En el fondo, todo eso está ligado a Token.

Notas del proyecto RAGFlow: funciones y uso de un motor RAG open source

Wed, 15 Apr 2026 22:09:25 +0800

RAGFlow es un motor RAG open source de infiniflow. Su objetivo no es ofrecer una simple capa de “sube documentos y haz preguntas”, sino reunir parsing de documentos, chunking, recuperación, reranking, trazabilidad de citas, configuración de modelos, capacidades de agentes e integración API en un flujo completo.

Si estás construyendo una base de conocimiento empresarial, Q&A sobre documentos, un asistente de soporte, recuperación de información interna o una capa de contexto más fiable para un LLM, RAGFlow es una de las opciones open source que merece atención seria.

01 Qué problema resuelve RAGFlow

La mayoría de sistemas RAG tropiezan con tres problemas comunes:

El parsing de documentos es inestable, especialmente con PDFs, escaneos, tablas, imágenes y layouts complejos.
La estrategia de chunking es opaca, así que la recuperación puede parecer correcta mientras el contexto real está incompleto.
Las respuestas no tienen citas confiables, lo que dificulta verificar de dónde viene la respuesta.

RAGFlow se centra justo en esos problemas. El README del proyecto enfatiza Deep document understanding, chunking basado en plantillas, visualización de chunks, grounding de citas y recuperación multipath con reranking. En otras palabras, le importa más que una entrada de alta calidad lleve a respuestas de alta calidad que simplemente conectar una base vectorial a una UI de chat.

02 Funciones principales

1. Comprensión profunda de documentos

RAGFlow puede extraer conocimiento de datos no estructurados complejos. El README lista formatos como Word, PPT, Excel, TXT, imágenes, documentos escaneados, datos estructurados y páginas web.

Esto importa mucho para bases de conocimiento empresariales. El material real rara vez es Markdown limpio. Suele mezclar contratos, informes, tablas, PDFs escaneados, manuales de producto, capturas y contenido web. Si el parsing es débil, tanto la recuperación como las respuestas del LLM sufrirán.

2. Chunking basado en plantillas

RAGFlow ofrece chunking basado en plantillas. El valor está en que el chunking no es una caja negra: distintos tipos de documentos pueden usar estrategias distintas.

Por ejemplo, artículos, papers, tablas, documentos Q&A, explicaciones de imágenes y cláusulas contractuales necesitan límites y granularidad de chunk diferentes. El chunking por plantillas ayuda a reducir frases rotas, pérdida de contexto de tablas y separación entre títulos y cuerpo.

3. Citas trazables

RAGFlow enfatiza citas fundamentadas, es decir, respuestas que pueden rastrearse hasta pasajes fuente. También ofrece visualización de chunks, facilitando inspeccionar y ajustar resultados de parsing y chunking.

Esto es especialmente importante en producción. El Q&A interno empresarial no solo necesita producir algo que parezca correcto; también debe ser verificable. Para políticas, cumplimiento, finanzas, documentación técnica y soporte al cliente, las citas y la trazabilidad son casi obligatorias.

4. Flujo RAG automatizado

RAGFlow convierte el ciclo de vida RAG en un flujo más completo:

Crear una base de conocimiento
Subir o sincronizar datos
Parsear documentos
Revisar y ajustar chunks
Configurar modelos LLM y embedding
Ejecutar recuperación multipath y reranking
Crear asistentes de chat
Integrar mediante APIs en sistemas de negocio

Eso lo acerca más a una plataforma RAG que a una librería aislada. Para equipos importan tanto la UI como la API: personas no técnicas pueden mantener la base de conocimiento y los ingenieros pueden integrar la capacidad en sistemas existentes.

5. Extensiones de Agent, MCP y workflow

Las actualizaciones recientes de RAGFlow ya incluyen Agentic workflow, MCP, Agent Memory y componentes de ejecución de código. Eso sugiere que ya no se limita al Q&A tradicional de bases de conocimiento y también se mueve hacia escenarios orientados a agentes.

Un patrón típico es que un agente use RAGFlow como capa fiable de conocimiento empresarial: recuperar contexto cuando lo necesita, generar respuestas con citas y combinarlo con herramientas o pasos de workflow cuando sea necesario.

03 Flujo básico de uso

Según la documentación oficial de quickstart, el uso común de RAGFlow puede resumirse en estos pasos.

1. Preparar el entorno

Los requisitos básicos listados en el README oficial son:

CPU >= 4 cores
RAM >= 16 GB
Disk >= 50 GB
Docker >= 24.0.0
Docker Compose >= v2.26.1

Si quieres usar el sandbox para el ejecutor de código, también necesitas gVisor. Otra nota práctica es que las imágenes Docker oficiales apuntan principalmente a plataformas x86. Para ARM64, la documentación recomienda construir la imagen por cuenta propia.

2. Clonar el proyecto

1
2

git clone https://github.com/infiniflow/ragflow.git
cd ragflow/docker

3. Revisar `vm.max_map_count`

El despliegue de RAGFlow depende de componentes como Elasticsearch u OpenSearch, así que en Linux normalmente hay que verificar:

`1`	`sysctl vm.max_map_count`

Si el valor está por debajo de 262144, puedes configurarlo temporalmente:

`1`	`sudo sysctl -w vm.max_map_count=262144`

Si quieres que persista tras reiniciar, añádelo a /etc/sysctl.conf.

4. Arrancar con Docker Compose

Puedes iniciar directamente el modo CPU:

`1`	`docker compose -f docker-compose.yml up -d`

Si quieres aceleración GPU para tareas DeepDoc, el README muestra cómo activar DEVICE=gpu en .env antes del arranque:

1
2

sed -i '1i DEVICE=gpu' .env
docker compose -f docker-compose.yml up -d

Luego inspecciona los logs:

`1`	`docker logs -f docker-ragflow-cpu-1`

Cuando los servicios estén listos, abre la dirección de la máquina en el navegador. Con la configuración predeterminada suele ser:

`1`	`http://IP_OF_YOUR_MACHINE`

5. Configurar claves API de modelos

RAGFlow necesita configuración de LLM y modelos de embedding. El README menciona elegir la fábrica LLM predeterminada en service_conf.yaml.template y actualizar el API_KEY correspondiente.

En la práctica, necesitas configurar modelos según tu proveedor:

Modelo de chat
Modelo de embedding
Modelo de rerank
Modelo multimodal, si quieres entender imágenes dentro de PDFs o DOCX

6. Crear la base de conocimiento y subir documentos

Después de arrancar el servicio, el flujo típico es:

Iniciar sesión en la Web UI.
Crear un dataset o base de conocimiento.
Subir documentos o configurar una sincronización de fuente de datos.
Esperar a que termine el parsing.
Inspeccionar los chunks y ajustarlos si hace falta.
Crear un asistente de chat y asociar la base de conocimiento.
Probar calidad de respuesta y fuentes de cita.

Si necesitas integrarlo con un sistema de negocio, puedes continuar con la API o SDK de RAGFlow y conectar recuperación y chat a tu propia aplicación.

04 Escenarios adecuados

RAGFlow encaja con necesidades como:

Q&A de bases de conocimiento internas empresariales
Manuales de producto, documentación técnica y recuperación de FAQ
Asistentes de soporte al cliente y preventa
Q&A trazable sobre contratos, informes y políticas
Manejo unificado de materiales multiformato
Equipos que quieren mantenimiento vía UI e integración API
Sistemas que quieren usar RAG como capa de contexto para agentes

Es especialmente adecuado cuando los formatos documentales son complejos, las citas importan y las personas quieren inspeccionar o intervenir en los resultados de parsing.

05 Qué vigilar

Primero, RAGFlow no es un script ligero. Tiene requisitos reales de infraestructura. La recomendación oficial es al menos 4 cores CPU, 16 GB de RAM y 50 GB de disco. Si solo quieres Q&A sobre una pequeña cantidad de Markdown, una plataforma completa puede ser innecesaria.

Segundo, la calidad documental sigue importando. RAGFlow puede mejorar parsing y chunking, pero no puede hacer mágicamente fiable material fuente de baja calidad, obsoleto o contradictorio. El gobierno de la base de conocimiento sigue siendo importante antes de producción.

Tercero, la selección de modelos afecta directamente la calidad. Las elecciones de embedding, rerank, chat y multimodal influyen en recuperación y respuestas. RAGFlow da el flujo, pero el resultado final sigue dependiendo de datos, modelos y ajuste.

Cuarto, los despliegues en producción deben cuidar permisos y seguridad de datos. Las bases de conocimiento empresariales suelen contener documentos internos, así que el modelo de despliegue, control de acceso, logs, claves API y políticas de datos del proveedor deben diseñarse de antemano.

06 Conclusión rápida

La fortaleza de RAGFlow es convertir las partes más difíciles de RAG en capacidades de plataforma: parsing de documentos complejos, chunking explicable, grounding de citas, recuperación multipath, reranking, configuración de modelos, Web UI, acceso API y extensiones de agentes.

Si necesitas una base de conocimiento empresarial verificable y mantenible que pueda conectarse a sistemas de negocio, RAGFlow es más completo que una configuración de “base vectorial más chat UI simple”. En cambio, si solo necesitas Q&A personal a pequeña escala sobre datos simples, un framework RAG más ligero puede ser más eficiente en recursos.

Enlaces relacionados

Proyecto GitHub: https://github.com/infiniflow/ragflow
Documentación oficial: https://ragflow.io/docs/dev/
Demo online: https://cloud.ragflow.io