Inicio / Artículos

ragvector-databasepageindexllmretrievalarchitecture

RAG sin vectores: cómo PageIndex lee documentos sin embeddings

RAG sin vectores con PageIndex: por qué la búsqueda vectorial por bloques pierde el contexto en informes largos, y cómo un índice de árbol basado en razonamiento encuentra la respuesta, con código.

Editor: REACTAPP.TOP15 min de lectura3480 palabras

Fuentes: I Deleted My Vector Database and My RAG System Got Better

Si le preguntas a alguien qué sucedió en el capítulo 7, no volverá a leer todo el libro. Abrirá el índice, irá directamente al capítulo 7 y leerá solo esa parte. Es rápido y preciso.

La mayoría de las herramientas de búsqueda de documentos basadas en IA no funcionan de esa manera. Dividen el texto en fragmentos arbitrarios, convierten cada fragmento en números y comparan la pregunta con los números que estén más cerca. A veces eso funciona bien. Otras veces la respuesta se encuentra en la frontera entre dos fragmentos y el sistema no la detecta. Un enfoque más reciente llamado RAG sin vectores abandona este método numérico y hace que el modelo analice la estructura de un documento de la misma forma que lo haría una persona. Se dice que alcanzó el 98,7% en una difícil prueba financiera, mientras que los métodos convencionales apenas llegaron al 50%. Lo que sigue explica cómo se logra ese resultado a partir de los principios básicos.

Qué hace RAG

RAG es la abreviatura de retrieval-augmented generation. En la práctica, significa darle a un modelo acceso a sus propios documentos para que sus respuestas provengan de esos datos y no solo de su entrenamiento.

Eso es importante porque modelos como GPT o Claude tienen un límite de conocimiento. Nunca han visto los informes internos, contratos legales ni registros médicos de ninguna organización en particular. RAG llena esa brecha al obtener pasajes relevantes y presentárselos al modelo justo antes de que responda. La promesa es sencilla: haz una pregunta y obtén una respuesta basada en tus propios materiales. La realidad es un poco más complicada.

La versión de fuerza bruta

El diseño más obvio consiste en pegar todo el documento en el prompt junto con la pregunta y dejar que el modelo lo organice. Sin bases de datos, sin mecanismos sofisticados.

from openai import OpenAI
import PyPDF2

client = OpenAI(api_key="your-api-key")

# Extract all text from a PDF
def extract_pdf_text(pdf_path):
    reader = PyPDF2.PdfReader(pdf_path)
    full_text = ""
    for page in reader.pages:
        full_text += page.extract_text() + "\n"
    return full_text

document_text = extract_pdf_text("annual_report.pdf")
user_question = "What was the total revenue in 2024?"

response = client.chat.completions.create(
    model="gpt-4.1",
    messages=[
        {"role": "system", "content": "Answer based on the provided document."},
        {"role": "user", "content": f"Document:\n{document_text}\n\nQuestion: {user_question}"}
    ]
)

print(response.choices[0].message.content)

Eso está bien para un PDF de cinco páginas. Un informe anual de 200 páginas choca rápidamente con esos límites.

  • Límites de contexto. Los modelos solo pueden procesar cierta cantidad de texto a la vez, y un documento de 200 páginas puede llegar a contener 300,000 tokens, más de lo que pueden manejar incluso los modelos más grandes.
  • Pérdida de calidad. Incluso si todo cupiera, las respuestas resultan vagas. Pedirle a un modelo que encuentre una aguja entre toda la paja hace que pierda el enfoque.
  • Costo. Los proveedores cobran por token, por lo que enviar 300,000 de ellos por cada pregunta, incluso si solo se responde con una página, suma rápidamente.

RAG fue creado precisamente para superar esos límites.

Cómo funciona el RAG vectorial

La idea es ingeniosa. Procesar el documento una sola vez, almacenar representaciones inteligentes de él en una base de datos y, al hacer una pregunta, recuperar solo las partes relevantes. El proceso consta de cinco etapas:

  1. Fragmentación. Dividir el documento en partes más pequeñas, quizás cada 500 palabras o un párrafo a la vez.
  2. Incrustación. Un modelo especializado convierte cada fragmento en una lista de números, un vector, que captura su significado. Las ideas similares obtienen números similares.
  3. Almacenamiento. Los vectores se guardan en una base de datos diseñada específicamente para ello, como ChromaDB, Pinecone o Weaviate. Milvus, Qdrant y la extensión PGVector para PostgreSQL son otras opciones comunes.
  4. Búsqueda. La pregunta también se incrusta, y la base de datos devuelve los fragmentos cuyos vectores están más cerca. Esa es la búsqueda por similitud.
  5. Generación. Los fragmentos recuperados y la pregunta se envían juntos al modelo, de modo que este trabaja a partir de un contexto enfocado.

Una versión funcional completa que utiliza ChromaDB y OpenAI se ve así:

from openai import OpenAI
import chromadb
import PyPDF2

client = OpenAI(api_key="your-api-key")

# Step 1: Extract and chunk the document
def extract_and_chunk(pdf_path, chunk_size=500):
    reader = PyPDF2.PdfReader(pdf_path)
    full_text = ""
    for page in reader.pages:
        full_text += page.extract_text() + "\n"

    words = full_text.split()
    chunks = []
    for i in range(0, len(words), chunk_size):
        chunk = " ".join(words[i:i + chunk_size])
        chunks.append(chunk)
    return chunks

chunks = extract_and_chunk("annual_report.pdf")

# Step 2 and 3: Embed and store in ChromaDB
chroma_client = chromadb.Client()
collection = chroma_client.create_collection("my_documents")

collection.add(
    documents=chunks,
    ids=[f"chunk_{i}" for i in range(len(chunks))]
)

# Step 4: Search for relevant chunks
user_question = "What was the total revenue in 2024?"

results = collection.query(
    query_texts=[user_question],
    n_results=5
)

relevant_chunks = "\n\n".join(results["documents"][0])

# Step 5: Generate answer with focused context
response = client.chat.completions.create(
    model="gpt-4.1",
    messages=[
        {"role": "system", "content": "Answer based only on the provided context."},
        {"role": "user", "content": f"Context:\n{relevant_chunks}\n\nQuestion: {user_question}"}
    ]
)

print(response.choices[0].message.content)

Hoy en día, la mayoría de las empresas utilizan algo similar. Funciona bien con preguntas sencillas sobre documentos simples, pero presenta limitaciones cuando los documentos se vuelven complejos.

Tres formas en que falla

Fragmentos que dividen una idea por la mitad

Imagínese un párrafo de un informe que indica que los ingresos operativos del tercer trimestre alcanzaron los 4.200 millones de dólares, un 12% más que el año anterior, principalmente debido a que los servicios en la nube generaron 2.800 millones de dólares en ingresos recurrentes (detalles en el Apéndice C). Si el rango de 500 palabras termina justo en medio de esa oración, un fragmento conservará la cifra pero perderá la explicación, mientras que el siguiente conservará la explicación pero perderá la cifra. Ninguno de los dos transmite la historia completa.

Es fácil reproducir este fallo:

paragraph = """The company's Q3 operating income was $4.2 billion,
representing a 12% increase over the prior year period. This growth
was primarily driven by the expansion of cloud services, which
contributed $2.8 billion in recurring revenue as detailed in the
segment breakdown in Appendix C."""

# Simulating a chunk boundary at word 20
words = paragraph.split()
chunk_1 = " ".join(words[:20])
chunk_2 = " ".join(words[20:])

print("Chunk 1:", chunk_1)
print("---")
print("Chunk 2:", chunk_2)

Si se pregunta qué causó el aumento de los ingresos operativos en el tercer trimestre, la búsqueda podría devolver la sección sobre servicios en la nube sin cifras, o la sección con las cifras pero sin indicar la causa. En cualquier caso, la respuesta es incompleta.

Dividir el texto en párrafos no soluciona el problema. Algunos párrafos tienen solo dos oraciones, mientras que otros ocupan media página, y tres párrafos consecutivos pueden contar una historia que solo tiene sentido si se leen juntos.

Referencias que no llevan a ninguna parte

Los contratos y los documentos financieros se basan en indicaciones como “La Sección 4.2.1 regula esto” o “Las tablas detalladas se encuentran en el Apéndice G”. Una pregunta sobre algo en la página 12 que hace referencia a datos de la página 87 probablemente llevará a la página 12, ya que las palabras clave coinciden, pero la búsqueda vectorial no sigue esa indicación hasta la página 87, donde se encuentran las cifras.

Una simulación rápida muestra el problema:

# Simulating a cross-reference failure
documents = {
    "page_12": "The company's debt-to-equity ratio improved significantly in 2024. For a full breakdown of long-term obligations, see Appendix G on page 87.",
    "page_45": "Marketing expenses increased by 15% due to new campaigns.",
    "page_87": "Appendix G: Long-term debt stands at $12.4B. Senior notes: $8.1B. Credit facility: $4.3B. Maturity schedule: 2026-2034."
}

# Vector RAG would likely return page_12 for a debt question
# but miss page_87 where the actual numbers live
# because "debt-to-equity ratio" is more similar to the query
# than "Senior notes" and "Credit facility"

Esto es común en contratos, documentos regulatorios y artículos académicos. La respuesta a menudo se encuentra en dos lugares al mismo tiempo, y un sistema que no pueda conectarlos siempre devolverá resultados incompletos.

Vocabulario que no coincide

La similitud vectorial depende en gran medida de que la redacción del usuario se parezca a la del documento. Si un informe menciona EBITDA ajustado según criterios no GAAP y el usuario pregunta por ganancias ajustadas, los vectores podrían no alinearse lo suficiente como para mostrar el fragmento correcto. La gente no conoce la terminología exacta de un documento, y no deberían necesitar conocerla.

La situación empeora en los campos técnicos. Un médico que busca protocolos de tratamiento para ataques cardíacos podría pasar por alto fragmentos escritos como vías de manejo del infarto miocárdico. El significado es idéntico, pero los vectores pueden estar lo suficientemente separados como para que los fragmentos adecuados nunca aparezcan.

Estos no son casos extremos raros. En documentos largos y estructurados en entornos de producción ocurren con regularidad.

Introducción al RAG sin vectores

En septiembre de 2025, un equipo de VectifyAI lanzó un marco llamado PageIndex que sigue un enfoque diferente. No divide los documentos ni compara números; en su lugar, crea un mapa estructurado del documento que permite a un modelo de IA razonar a través de él.

La inspiración proviene de la forma en que trabajan realmente los expertos. Un analista recibe un informe de 200 páginas; quien necesita una cifra concreta no lee todas las páginas. Consulta el índice, elige la sección más probable que contenga la respuesta y la lee detenidamente. Si dice “ver Apéndice G”, se dirige al Apéndice G.

PageIndex hace que un modelo se comporte de la misma manera. La idea clave es que el texto más similar no siempre es el texto más relevante. Una base de datos vectorial devuelve lo que se parece más a la pregunta, pero a veces la respuesta se encuentra en una sección que no se parece en nada a ella. Lo que se necesita es razonar sobre dónde debería estar la respuesta, no realizar búsquedas por patrones.

El sistema funciona en dos pasos.

Paso uno: un índice en forma de árbol

En lugar de dividir el texto en fragmentos e incrustarlo, el documento se pasa a un modelo de razonamiento que lo estructura como un árbol. Imagínese a un becario competente que lee todo el informe y elabora un índice multinivel, donde cada entrada contiene un título, un breve resumen, un rango de páginas y enlaces a sus subentradas. Un informe financiero podría quedar así:

Root: Annual Report 2024
  |-- Executive Summary (pages 1-3)
  |     Summary: "Overview of company performance, key metrics..."
  |-- Financial Statements (pages 15-45)
  |     |-- Income Statement (pages 15-20)
  |     |-- Balance Sheet (pages 21-30)
  |     +-- Cash Flow Statement (pages 31-45)
  |-- Risk Factors (pages 46-60)
  +-- Appendices (pages 80-120)
        |-- Appendix A: Segment Data (pages 80-95)
        +-- Appendix G: Detailed Tables (pages 96-120)

No hay vectores ni embeddings, solo una estructura lógica que coincide con la forma en que está organizado el documento. El modelo utiliza su razonamiento para detectar límites naturales como los saltos de capítulo, los cambios de tema y las nuevas secciones, en lugar de dividirlo según un número fijo de palabras.

Paso dos: búsqueda basada en el razonamiento

En el momento de la consulta, al modelo solo se le muestra el árbol, nunca todo el documento. Escanea los títulos y resúmenes, aplica sus propios conocimientos del dominio y elige los nodos que parecen tener más probabilidades de contener la respuesta.

Considere una pregunta sobre el cambio interanual en el margen operativo. El razonamiento del modelo es más o menos el siguiente: los márgenes son una métrica financiera, por lo que la cuenta de resultados es importante, pero una comparación interanual también podría requerir cifras anteriores, quizás en el apéndice. El sistema responde con los IDs de nodo de ambas secciones, extrae únicamente el texto original de esas dos secciones y redacta la respuesta final a partir de ese contexto restringido.

Una demostración funcional del concepto no necesita nada más que llamadas simples a OpenAI:

import json
from openai import OpenAI
import PyPDF2

client = OpenAI(api_key="your-api-key")

# Extract text page by page
def extract_pages(pdf_path):
    reader = PyPDF2.PdfReader(pdf_path)
    pages = {}
    for i, page in enumerate(reader.pages):
        pages[i + 1] = page.extract_text()
    return pages

pages = extract_pages("annual_report.pdf")
all_text = "\n".join([f"--- Page {k} ---\n{v}" for k, v in pages.items()])

# Step 1: Build the tree index using AI reasoning
tree_prompt = f"""You are a document analyst. Read this document and create
a hierarchical table of contents as a JSON tree. Each node should have:
- "title": section name
- "summary": 2-3 sentence description of what this section covers
- "pages": [start_page, end_page]
- "children": array of child nodes (or empty array)

Document:
{all_text[:80000]}

Return ONLY valid JSON. No other text."""

tree_response = client.chat.completions.create(
    model="gpt-4.1",
    messages=[{"role": "user", "content": tree_prompt}],
    response_format={"type": "json_object"}
)

document_tree = json.loads(tree_response.choices[0].message.content)
print("Document tree built successfully!")
print(json.dumps(document_tree, indent=2)[:500])

# Step 2: Reasoning-based search over the tree
user_question = "What was the year-over-year change in operating margin?"

search_prompt = f"""You are a retrieval expert. Given a user question and
a document's table of contents tree, identify which sections are most
likely to contain the answer.

Think step by step:
1. What kind of information does the question ask for?
2. Which sections would a human expert check first?
3. Are there sections that might cross-reference each other?

Document tree:
{json.dumps(document_tree, indent=2)}

Question: {user_question}

Return JSON with:
- "reasoning": your step-by-step thought process
- "relevant_pages": list of page numbers to retrieve"""

search_response = client.chat.completions.create(
    model="gpt-4.1",
    messages=[{"role": "user", "content": search_prompt}],
    response_format={"type": "json_object"}
)

search_result = json.loads(search_response.choices[0].message.content)
print("Reasoning:", search_result["reasoning"])

# Step 3: Fetch only relevant pages and generate answer
relevant_text = ""
for page_num in search_result["relevant_pages"]:
    if page_num in pages:
        relevant_text += f"\n--- Page {page_num} ---\n{pages[page_num]}"

answer_response = client.chat.completions.create(
    model="gpt-4.1",
    messages=[
        {"role": "system", "content": "Answer precisely based on the document context provided."},
        {"role": "user", "content": f"Context:{relevant_text}\n\nQuestion: {user_question}"}
    ]
)

print("\nAnswer:", answer_response.choices[0].message.content)

Así que todo el truco cabe en una sola oración: omite el almacén de vectores, omite las representaciones vectoriales, omite el ajuste del tamaño de los fragmentos, y deja que el modelo estudie el esquema, decida dónde debe estar la respuesta y obtenga solo esas secciones.

Uso del framework PageIndex

La versión para hacerlo uno mismo es útil para aprender. Para proyectos reales, PageIndex se encarga de la mayor parte del trabajo: genera árboles optimizados, admite estrategias de búsqueda más avanzadas y está disponible como servicio en la nube o como opción autohospedada. El uso básico es el siguiente:

from pageindex import PageIndexClient
import time

# Initialize the client
pi_client = PageIndexClient(api_key="your-pageindex-api-key")

# Upload and process your document
result = pi_client.submit_document("./annual_report.pdf")
doc_id = result["doc_id"]

# Wait for processing to complete
while True:
    status = pi_client.get_document(doc_id)["status"]
    if status == "completed":
        print("Document processed!")
        break
    time.sleep(5)

# Inspect the generated tree structure
tree_result = pi_client.get_tree(doc_id)
if tree_result.get("status") == "completed":
    tree = tree_result["result"]
    for node in tree:
        print(f"[{node['node_id']}] {node['title']} - Page {node['page_index']}")

# Ask questions using the Chat API
response = pi_client.chat_completions(
    messages=[{"role": "user", "content": "What was total revenue in FY2024 vs FY2023?"}],
    doc_id=doc_id
)

print(response["choices"][0]["message"]["content"])

El árbol generado tiene esta forma:

{
  "title": "Financial Stability",
  "node_id": "0006",
  "page_index": 21,
  "text": "The Federal Reserve maintains financial stability...",
  "nodes": [
    {
      "title": "Monitoring Financial Vulnerabilities",
      "node_id": "0007",
      "page_index": 22,
      "text": "The Federal Reserve's monitoring focuses on..."
    },
    {
      "title": "Domestic and International Cooperation",
      "node_id": "0008",
      "page_index": 28,
      "text": "In 2023, the Federal Reserve collaborated..."
    }
  ]
}

Cada nodo cuenta con un ID único que hace referencia al documento original, un título, el texto en sí y nodos hijos para las subsecciones. El modelo recorre el árbol leyendo los resúmenes y decidiendo qué ramas abrir más a fondo.

Se pueden comparar varios documentos en una sola consulta:

response = pi_client.chat_completions(
    messages=[{"role": "user", "content": "Compare the results across these two reports."}],
    doc_id=["pi-abc123def456", "pi-abc123ghi789"]
)

Los desarrolladores que crean agentes con LangChain, CrewAI o el SDK de OpenAI Agents pueden conectar PageIndex a través del Protocolo de Contexto de Modelo (MCP), lo que permite a un agente utilizarlo como herramienta de recuperación de información sin necesidad de código de integración personalizado.

El estándar de referencia detrás de esta afirmación

FinanceBench es el estándar de referencia que dio a conocer el enfoque RAG sin vectores. Sus preguntas provienen de documentos reales presentados ante la SEC (informes 10-K y 10-Q) y exigen respuestas precisas: cifras extraídas de tablas, cálculos con varios pasos y referencias cruzadas entre diferentes secciones. Nada de esto es un ejercicio práctico sin importancia.

Los métodos convencionales de RAG basados en vectores obtienen puntuaciones entre el 30% y el 50% en este estándar. PageIndex, gracias a su motor de razonamiento Mafin 2.5, alcanzó una puntuación del 98.7%, lo que representa una diferencia abismal y un aumento significativo. Se mencionan constantemente tres razones para ello:

  • Seguimiento de referencias cruzadas. Cuando un documento indica “ver Apéndice G”, el modelo de razonamiento navega por el árbol hasta el Apéndice G y obtiene esos datos. Un almacén de vectores no tiene idea de que debe seguir el puntero.
  • Mantenimiento de la estructura intacta. Una tabla financiera contiene encabezados, encabezados anidados, notas al pie y enlaces entre celdas. Las secciones en forma de árbol mantienen todo esto unido dentro de límites claros, mientras que el particionamiento de tamaño fijo lo separa.
  • Razonamiento multi-paso. Para solicitar el cambio interanual en el margen operativo se necesitan números de dos secciones además de un cálculo. El modelo de razonamiento determina que necesita ambos y los obtiene juntos, mientras que una búsqueda por similitud probablemente solo recuperaría el fragmento más cercano a la formulación de la pregunta.

Una advertencia importante: a principios de 2026, el equipo de PageIndex aún no había publicado cifras detalladas sobre velocidad o rendimiento. Cada consulta requiere varias llamadas secuenciales al modelo para el análisis y el razonamiento, por lo que es más lenta y costosa por consulta que una búsqueda vectorial simple. Para usos de alto volumen y baja latencia, este compromiso podría no ser adecuado.

Elegir entre ellos

El RAG sin vectores no es un reemplazo universal para las bases de datos vectoriales; es una herramienta especializada.

El RAG vectorial es adecuado cuando las respuestas deben llegar en menos de un segundo, cuando el corpus está formado por muchos documentos cortos como una base de Preguntas Frecuentes o una colección de artículos, cuando el costo por consulta supera a la precisión perfecta, o cuando un chatbot para consumidores puede funcionar con respuestas suficientemente buenas.

El RAG sin vectores es adecuado para documentos profesionales largos y estructurados: informes anuales, contratos, documentos regulatorios y manuales técnicos. También resulta útil en casos en los que la precisión es prioritaria, cuando las consultas deben seguir referencias cruzadas, o cuando se necesita un registro de auditoría claro que muestre de dónde proviene cada parte de la respuesta.

Un enfoque híbrido merece ser considerado para entornos de producción. Los metadatos ligeros o los filtros por palabras clave pueden determinar qué documentos son relevantes, y luego el razonamiento basado en árboles localiza las secciones exactas dentro de ellos. Esto ofrece la velocidad de la búsqueda tradicional en la primera pasada y la precisión del razonamiento en la segunda.

La relación costo-beneficio es real. Los modelos basados en razonamiento cuestan más por llamada que los modelos de incrustación, y el recorrido por árboles implica múltiples llamadas secuenciales y una mayor latencia. La velocidad y el precio se intercambian por la precisión y la explicabilidad. En campos regulados como las finanzas, el derecho y la salud, donde las respuestas incorrectas tienen consecuencias, ese intercambio suele ser beneficioso.

La dirección que toma esto

El paso de la recuperación basada en similitud a la basada en razonamiento es reciente, pero la dirección es clara. PageIndex ya admite una variante basada en visión que funciona directamente con imágenes de páginas PDF, sin necesidad de extracción de texto ni OCR. Se introducen las imágenes de las páginas y el modelo razona sobre lo que ve. Esto ayuda con diseños complejos, páginas escaneadas y gráficos incrustados, que la extracción de texto maneja mal.

También se está trabajando en la recuperación basada en agentes. En lugar de realizar una sola pasada, el modelo sigue explorando: sigue las referencias, compara secciones, se hace preguntas de seguimiento a sí mismo y perfecciona su respuesta a través de varias rondas de razonamiento, lo cual representa la diferencia entre echar un vistazo rápido a un documento y estudiarlo en profundidad.

Cualquiera que quiera experimentar puede utilizar el repositorio de código abierto PageIndex en GitHub, que cuenta con cuadernos de trabajo Jupyter listos para ejecutarse tanto para los pipelines estándar como los basados en visión. El proyecto superó las 20,000 estrellas desde su lanzamiento en septiembre de 2025, y su canal de Discord está activo.

Las bases de datos vectoriales seguirán existiendo, ya que manejan eficazmente una gran cantidad de cargas de trabajo. Sin embargo, son cada vez más las aplicaciones que dependen de un análisis profundo de documentos largos e intrincados, y el método de dividir el texto en fragmentos de tamaño fijo con la esperanza de que una búsqueda de similitud encuentre el fragmento correcto se está volviendo insuficiente. Los contratos, los documentos legales y las especificaciones técnicas son precisamente los documentos que más valoran las empresas, y es allí donde la recuperación basada en razonamiento da los mejores resultados.

La forma sensata de evaluarlo es probar la versión casera en un documento que ya se entienda bien, luego probar PageIndex en el mismo archivo y observar cómo el árbol estructurado mantiene la organización que la división en fragmentos destruye. El mejor sistema de recuperación no es el que cuenta con la tecnología más sofisticada, sino el que logra encontrar la respuesta correcta.

Una forma de probarlo

  • Vector RAG, adecuado para los conceptos básicos: instale chromadb y openai, ejecute el ejemplo de ChromaDB con un documento corto, luego pruebe con uno más largo y observe en qué puntos las respuestas se vuelven menos precisas.
  • Enfoque sin vectores hecho por uno mismo, útil para comprender el concepto: ejecute el ejemplo sencillo de árboles y razonamiento de OpenAI con el mismo documento y compare las respuestas con la versión basada en vectores.
  • Enfoque sin vectores para producción: obtenga una clave API gratuita de PageIndex desde el sitio de documentación, instale el paquete Python pageindex y siga el ejemplo del SDK. Suba un documento real y haga preguntas cuyas respuestas ya se conozcan, ya que esta es la forma más rápida de evaluar su idoneidad.

Todos los ejemplos utilizan Python 3.10 o superior, junto con el SDK de OpenAI, ChromaDB y PyPDF2, instalados mediante pip install openai chromadb PyPDF2 pageindex. Se necesita una clave API de OpenAI, además de una clave de PageIndex para los ejemplos relacionados con esta plataforma.

Leer más

← Todos los artículosEnviar el brief