RAG sans vecteurs : comment PageIndex lit les documents sans embeddings

Si vous demandez à quelqu’un ce qui s’est passé au chapitre 7, il n’aura pas besoin de relire tout le livre. Il ouvrira le sommaire, ira directement au chapitre 7 et lira uniquement cette partie. C’est rapide et précis.

La plupart des systèmes de recherche de documents basés sur l’IA ne fonctionnent pas de cette manière. Ils divisent le texte en fragments arbitraires, transforment chaque fragment en nombres, puis comparent la question aux nombres les plus proches. Cela peut être suffisant parfois. Mais parfois, la réponse se situe à la frontière entre deux fragments, et le système ne la détecte pas. Une approche plus récente appelée RAG sans vecteurs élimine cette méthode basée sur les nombres et fait en sorte que le modèle comprenne la structure d’un document comme le ferait une personne. On rapporte qu’elle a atteint 98,7 % dans un test financier difficile, alors que les méthodes conventionnelles ne dépassaient à peine 50 %. Ce qui suit explique comment ce résultat est obtenu à partir des principes de base.

Qu’est-ce que fait RAG

RAG signifie génération augmentée par la récupération d’informations. En pratique, cela consiste à donner à un modèle accès à vos propres documents afin que ses réponses proviennent de vos données et non seulement de son entraînement.

Cela est important car des modèles comme GPT ou Claude ont une date de fin de connaissance. Ils n’ont jamais vu les rapports internes, les contrats juridiques ou les dossiers médicaux d’une organisation donnée. RAG comble cette lacune en récupérant des passages pertinents et en les présentant au modèle juste avant qu’il ne réponde. La promesse est simple : poser une question et obtenir une réponse basée sur vos documents. La réalité est cependant plus complexe.

La version par force brute

La solution la plus évidente consiste à intégrer l’intégralité du document dans la demande, aux côtés de la question, et à laisser le modèle s’en occuper. Aucune base de données, aucune mécanique sophistiquée requise.

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)

C’est acceptable pour un PDF de cinq pages. Un rapport annuel de 200 pages se heurte rapidement à ces limites.

• Limites de contexte. Les modèles ne peuvent traiter qu’une certaine quantité de texte à la fois, et un document de 200 pages peut atteindre 300 000 tokens, dépassant la capacité même des modèles les plus grands.
• Perte de qualité. Même si tout tenait dans le contexte, les réponses deviennent vagues. Demander à un modèle de trouver une aiguille parmi toute une botte de foin le fait perdre son focus.
• Coût. Les fournisseurs facturent par token, donc envoyer 300 000 tokens pour chaque question, même si celle-ci est résolue en une seule page, entraîne des coûts élevés rapidement.

RAG a été inventé justement pour contourner ces limites.

Comment fonctionne le RAG vectoriel

L’idée est intéressante : traiter le document une seule fois, en stocker des représentations intelligentes dans une base de données, puis ne récupérer que les parties pertinentes au moment de la question. Le processus comporte cinq étapes :

1. Fragmentation. Diviser le document en parties plus petites, par exemple tous les 500 mots ou un paragraphe à la fois.
2. Incorporation. Un modèle spécialisé convertit chaque fragment en une liste de nombres, un vecteur, qui en capture le sens. Des idées similaires aboutissent à des nombres similaires.
3. Stockage. Les vecteurs sont stockés dans une base de données conçue à cet effet, telle que ChromaDB, Pinecone ou Weaviate. Milvus, Qdrant et l’extension PGVector pour PostgreSQL sont d’autres options courantes.
4. Recherche. La question est également incorporée, et la base de données renvoie les fragments dont les vecteurs sont les plus proches. C’est ce qu’on appelle une recherche de similarité.
5. Génération. Les fragments récupérés ainsi que la question sont envoyés ensemble au modèle, ce qui lui permet de travailler à partir d’un contexte ciblé.

Une version fonctionnelle complète utilisant ChromaDB et OpenAI se présente comme suit :

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)

La plupart des entreprises utilisent aujourd’hui des systèmes similaires. Ils gèrent bien les questions simples concernant des documents basiques, mais ils présentent des limites dès que les documents deviennent complexes.

Trois manières dont ils échouent

Tronçons qui coupent une idée en deux

Imaginons un paragraphe de rapport indiquant que le chiffre d’affaires d’exploitation du troisième trimestre a atteint 4,2 milliards de dollars, soit une hausse de 12 % par rapport à l’année précédente, principalement grâce aux services cloud qui ont généré 2,8 milliards de dollars de revenus récurrents (détails à l’Appendice C). Si une fenêtre de 500 mots se termine par hasard au milieu de cette phrase, un tronçon conserve le chiffre mais perd l’explication, tandis que l’autre conserve l’explication mais perd le chiffre. Aucun des deux ne raconte l’histoire dans son intégralité.

Cet échec est facile à reproduire :

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 l’on demande ce qui a provoqué l’augmentation du résultat d’exploitation au troisième trimestre, la recherche peut renvoyer au paragraphe concernant les services cloud sans chiffres, ou au paragraphe contenant les chiffres mais sans explication. Dans les deux cas, la réponse est incomplète.

Diviser le texte en paragraphes ne résout pas le problème. Certains paragraphes ne comptent que deux phrases tandis que d’autres occupent la moitié d’une page, et trois paragraphes consécutifs peuvent raconter une histoire qui n’a de sens que lue ensemble.

Références qui mènent nulle part

Les contrats et les documents financiers font appel à des indications telles que « La section 4.2.1 régit cela » ou « Les tableaux détaillés se trouvent à l’Appendice G ». Une question concernant un élément de la page 12 qui fait référence à des données de la page 87 aboutira probablement à la page 12, car les mots-clés correspondent, mais aucune recherche vectorielle ne suit cette indication vers la page 87 où se trouvent les chiffres.

Une simulation rapide montre le problème :

# 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"

Cela est courant dans les contrats, les dossiers réglementaires et les articles académiques. La réponse se trouve souvent en même temps en deux endroits, et un système incapable de les relier renverra toujours des résultats incomplets.

Vocabulaire qui ne correspond pas

La similarité vectorielle dépend fortement du fait que les termes utilisés par l’utilisateur ressemblent à ceux du document. Si un rapport mentionne l’EBITDA ajusté selon les normes non-GAAP et que l’utilisateur demande des informations sur les bénéfices ajustés, les embeddings peuvent ne pas correspondre suffisamment bien pour afficher le fragment approprié. Les gens ne connaissent pas toujours la terminologie exacte d’un document, et ils n’ont pas besoin de la connaître.

La situation s’aggrave dans les domaines techniques. Un médecin cherchant des protocoles de traitement des crises cardiaques risque de manquer des fragments décrits comme des méthodes de gestion de l’infarctus du myocarde. Le sens est identique, mais les vecteurs peuvent être suffisamment éloignés les uns des autres pour que les fragments pertinents n’apparaissent jamais.

Ces cas limites ne sont pas rares. Dans les documents longs et structurés utilisés en production, ils se produisent régulièrement.

Apparition du RAG sans vecteurs

En septembre 2025, une équipe de VectifyAI a publié un cadre appelé PageIndex qui emprunte une approche différente. Il ne divise pas les documents ni ne compare des numéros ; il crée plutôt une carte structurée du document permettant à un modèle d’IA de s’y repérer.

Cette idée s’inspire de la manière dont travaillent réellement les experts. Lorsqu’un analyste remet un rapport de 200 pages à quelqu’un qui n’a besoin que d’une seule donnée, cette personne ne lit pas chaque page. Elle consulte le sommaire, choisit la section la plus susceptible de contenir la réponse et la lit attentivement. Si cela indique « voir l’Appendice G », elle se tourne vers l’Appendice G.

PageIndex fait en sorte que un modèle se comporte de la même manière. L’idée clé est que le texte le plus similaire n’est pas toujours le texte le plus pertinent. Une base de données vectorielle renvoie tout ce qui ressemble le plus à la question, mais la réponse se trouve parfois dans une section qui ne lui ressemble pas du tout. Ce qui est nécessaire, c’est une réflexion sur l’endroit où la réponse devrait se trouver, et non une simple correspondance de motifs.

Le système fonctionne en deux étapes.

Étape un : un index en arbre

Plutôt que de diviser le document en fragments et de les vectoriser, celui-ci est transmis à un modèle de raisonnement qui le représente sous forme d’arbre. Imaginez un stagiaire compétent qui lit l’intégralité du rapport et rédige un sommaire à plusieurs niveaux, où chaque entrée contient un titre, un bref résumé, une plage de pages et des liens vers ses sous-entrées. Un rapport financier pourrait ressembler à ceci :

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)

Aucun vecteur ni aucune embedding, seulement une structure logique correspondant à l’organisation du document. Le modèle utilise son raisonnement pour détecter des frontières naturelles telles que les sauts de chapitre, les changements de sujet et de nouvelles sections, plutôt que de se baser sur un nombre fixe de mots.

Deuxième étape : recherche basée sur le raisonnement

Lors de la recherche, le modèle ne voit que l’arbre, jamais le document entier. Il examine les titres et les résumés, fait appel à ses propres connaissances sectorielles, et choisit les nœuds qui semblent le plus susceptibles de contenir la réponse.

Considérons une question concernant l’évolution annuelle du marges opérationnelle. Le raisonnement du modèle est plus ou moins le suivant : les marges étant une métrique financière, le compte de résultat est pertinent, mais une comparaison annuelle peut également nécessiter des données antérieures, éventuellement dans l’annexe. Le système répond en indiquant les identifiants des deux sections ; il ne récupère que le texte original de ces deux sections, et la réponse finale est élaborée à partir de ce contexte restreint.

Une démonstration fonctionnelle de ce concept ne nécessite rien de plus que des appels simples à 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)

Tout le truc se résume en une phrase : évitez le stockage vectoriel, évitez les embeddings, évitez l’ajustement de la taille des blocs, et laissez le modèle examiner l’aperçu, déterminer où se trouve la réponse et ne récupérer que ces sections.

Utilisation du framework PageIndex

La version faite soi-même convient bien pour apprendre. Pour des projets réels, PageIndex s’occupe du travail difficile : il génère des arbres optimisés, prend en charge des stratégies de recherche plus avancées, et est disponible en tant que service cloud ou en version auto-hébergée. L’utilisation de base se présente comme suit :

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"])

L’arbre généré a cette forme :

{
  "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..."
    }
  ]
}

Chaque nœud possède un ID unique renvoyant au document d’origine, un titre, le texte lui-même ainsi que des nœuds enfants pour les sous-sections. Le modèle parcourt l’arbre en lisant les résumés et en déterminant quels branches ouvrir en détail.

Plusieurs documents peuvent être comparés dans une seule requête :

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

Les développeurs qui créent des agents avec LangChain, CrewAI ou l’OpenAI Agents SDK peuvent se connecter à PageIndex via le Model Context Protocol (MCP), ce qui permet à un agent de l’utiliser comme outil de recherche sans code d’intégration personnalisé.

Le benchmark à l’origine de cette affirmation

FinanceBench est le benchmark qui a mis en lumière les capacités du RAG non vectoriel. Ses questions proviennent de vrais documents déposés auprès de la SEC (rapports 10-K et 10-Q) et exigent des réponses précises : des chiffres extraits de tableaux, des calculs en plusieurs étapes, ainsi que des références croisées entre différentes sections. Il ne s’agit en aucun cas d’un exercice de simulation.

Les méthodes classiques de RAG vectoriel obtiennent des scores d’environ 30 % à 50 % sur ce benchmark. PageIndex, grâce à son moteur de raisonnement Mafin 2.5, a atteint un score de 98,7 %, ce qui représente une différence considérable et un gain significatif. Trois raisons reviennent constamment :

• Suivi des références croisées. Lorsqu’un document indique « voir l’Appendice G », le modèle de raisonnement navigue dans l’arborescence jusqu’à l’Appendice G et récupère les données correspondantes. Un stockage vectoriel n’a aucune idée qu’il doit suivre ce pointeur.
• Préservation de la structure. Un tableau financier comprend des en-têtes, des en-têtes imbriqués, des notes de bas de page et des liens entre cellules. Les sections arborescentes maintiennent tout cela ensemble au sein de limites claires, tandis qu’un découpage en blocs de taille fixe les sépare.
• Raisonnement à plusieurs étapes. Pour obtenir l’évolution annuelle du marges opérationnelle, il faut des chiffres provenant de deux sections ainsi qu’un calcul. Le modèle de raisonnement détermine qu’il a besoin des deux éléments et les récupère ensemble, alors que une recherche par similarité ne récupérerait probablement que le bloc le plus proche de la formulation de la question.

Une mise en garde importante : au début de 2026, l’équipe PageIndex n’avait pas publié de chiffres détaillés concernant la vitesse ou le débit. Chaque requête nécessite plusieurs appels séquentiels au modèle pour effectuer la navigation et le raisonnement, ce qui la rend plus lente et plus coûteuse par requête qu’une simple recherche vectorielle. Pour des utilisations à fort volume et à faible latence, cet équilibre peut ne pas être adapté.

Choisir entre les deux

Le RAG sans vecteurs n’est pas un remplaçant universel pour les bases de données vectorielles. C’est un outil spécialisé.

Le RAG vectoriel est adapté lorsque les réponses doivent être fournies en moins d’une seconde, lorsque le corpus se compose de nombreux documents courts tels qu’une base de FAQ ou une collection d’articles, lorsque le coût par requête l’emporte sur une précision parfaite, ou lorsque un chatbot grand public peut se contenter de réponses suffisamment bonnes.

Le RAG sans vecteurs convient aux documents professionnels longs et structurés : rapports annuels, contrats, dossiers réglementaires et manuels techniques. Il est également adapté aux cas où la précision est primordiale, où les requêtes doivent suivre des références croisées, ou où un historique d’audit clair doit indiquer d’où provient chaque partie d’une réponse.

Un système hybride mérite d’être envisagé pour un usage en production. Des métadonnées légères ou des filtres de mots-clés permettent de réduire le nombre de documents pertinents, puis un raisonnement basé sur des arbres permet de trouver les sections exactes à l’intérieur d’eux. Cela offre la vitesse de la recherche traditionnelle dès la première tentative, ainsi que la précision du raisonnement lors de la seconde.

Le compromis coût/performance est réel. Les modèles de raisonnement coûtent plus par appel que les modèles d’incorporation, et la parcours des arbres implique de multiples appels séquentiels ainsi qu’une latence plus élevée. La vitesse et le prix sont échangés contre la précision et l’explicabilité. Dans des domaines réglementés tels que la finance, le droit et la santé, où des réponses erronées ont des conséquences, cet échange s’avère généralement rentable.

La direction future

Le passage d’une recherche basée sur la similarité à une recherche basée sur le raisonnement est encore récent, mais la direction est claire. PageIndex prend déjà en charge une version basée sur l’analyse visuelle qui fonctionne directement sur les images des pages PDF, sans extraction de texte ni OCR. Les images des pages sont saisies, et le modèle raisonne à partir de ce qu’il voit. Cela aide à gérer des layouts complexes, des pages scannées et des graphiques intégrés, que l’extraction de texte traite mal.

Le travail sur la récupération agente est également en cours. Au lieu d’une seule passe, le modèle continue d’explorer : il suit les références, compare les sections, se pose des questions de suivi et affine sa réponse au cours de plusieurs tours de raisonnement, ce qui représente la différence entre parcourir un document rapidement et l’étudier en profondeur.

Tout ceux qui souhaitent expérimenter peuvent utiliser le dépôt open source PageIndex sur GitHub, qui propose des notebooks Jupyter exécutables pour les pipelines standards ainsi que ceux basés sur la vision. Le projet a atteint 20 000 étoiles depuis son lancement en septembre 2025, et son serveur Discord est actif.

Les bases de données vectorielles resteront, et elles gèrent très bien de nombreux types de charges de travail. Cependant, les applications qui nécessitent une lecture approfondie de documents longs et complexes se multiplient, et la méthode consistant à diviser le texte en tronçons de taille fixe dans l’espoir qu’une recherche de similarité révèle le bon tronçon devient de moins en moins efficace. Les contrats, les dossiers juridiques et les spécifications techniques sont précisément les documents que les entreprises valorisent le plus, et c’est là que la récupération basée sur le raisonnement est la plus utile.

La manière sensée d’évaluer cela consiste à tester la version « faites-le-vous-même » sur un document déjà bien compris, puis d’essayer PageIndex sur le même fichier pour voir comment l’arborescence permet de conserver l’organisation que le découpage fragmente. Le meilleur système de récupération n’est pas celui qui utilise la technologie la plus sophistiquée, mais celui qui trouve la bonne réponse.

Une façon de l’essayer

• Vector RAG, idéal pour les bases : installez chromadb et openai, exécutez l’exemple de ChromaDB sur un document court, puis essayez avec un document plus long et observez où les réponses deviennent moins fiables.
• Méthode sans vecteurs faite soi-même, utile pour comprendre le concept : exécutez l’exemple simple d’OpenAI basé sur l’arbre de raisonnement sur le même document et comparez les réponses avec celles de la version vectorielle.
• Méthode sans vecteurs en environnement de production : obtenez une clé API gratuite PageIndex sur le site des documents, installez le paquet Python pageindex et suivez l’exemple du SDK. Téléchargez un document réel et posez des questions dont les réponses sont déjà connues, c’est le moyen le plus rapide pour évaluer l’adéquation.

Tous les exemples utilisent Python 3.10 ou ultérieur avec le SDK d’OpenAI, ChromaDB et PyPDF2, installés via pip install openai chromadb PyPDF2 pageindex. Une clé API d’OpenAI est nécessaire, ainsi qu’une clé PageIndex pour les exemples PageIndex.