Build with usConstruire avec nous
04 · From documents to cited responseArchived
04 · Des documents à la réponse citéeArchivé

Build retrieval around evidence, not a demo prompt.Construisez la recherche autour des preuves, pas d’un prompt de démonstration.

Archived, downloadable architecture source for extracting legal material, creating retrievable units and carrying evidence toward a cited answer.Une source d’architecture archivée et téléchargeable pour extraire le droit, créer des unités retrouvables et porter les preuves vers une réponse citée.

View on GitHubDiscuss the archive
Voir sur GitHubDiscuter de l’archive
https://github.com/AndriusPetrenas/QueryLexV6 · 401928a0d20107545673641e228a9869b1806c16 · /solutions/rag-builder
RAG BUILDER
ARCHITECTURE SOURCE
01Ingest
02Parse + chunk
03Embed + index
04Retrieve
05Rerank
06Answer + cite
07Evaluate
PINNED ARCHIVED SOURCE7 INSPECTABLE STAGES
RAG BUILDER
SOURCE D’ARCHITECTURE
01Ingérer
02Analyser + segmenter
03Vectoriser + indexer
04Rechercher
05Reclasser
06Répondre + citer
07Évaluer
SOURCE ARCHIVÉE ÉPINGLÉE7 ÉTAPES INSPECTABLES
Product factsFiche produit
StateArchived
Deployment

Not hosted

Data boundary

No active ingestion or retrieval endpoint

Last updated
ÉtatArchivé
Déploiement

Non hébergé

Données

Aucun endpoint actif d’ingestion ou de recherche

Mise à jour
Architecture evidence

This captured schema explains the architecture; it is not a builder interface.

The manifested image is source-code proof captured from this site’s native architecture schema. The downloadable Python package is pinned separately to the historical commit where it exists.

Preuve d’architecture

Ce schéma capturé explique l’architecture ; ce n’est pas une interface du builder.

L’image du manifeste est une preuve issue du code source, capturée depuis le schéma d’architecture natif de ce site. Le package Python téléchargeable est épinglé séparément au commit historique où il existe.

Product architectureArchitecture du produit401928a
Native two-rail RAG pipeline architecture showing documents-to-data and question-to-answer stages.
Pipeline architectureArchitecture du pipelineSource-code evidencePreuve issue du code source/solutions/rag-builder · 2026-07-31
Source and evidence limitsSource et limites de la preuve
  • Architecture and source-code proof only; this is not a builder product interface.
  • The public package CTA is pinned to its historical repository commit because the package is absent from the current primary branch snapshot.
  • No hosted RAG execution, model call, or customer dataset is represented.
  • Preuve d’architecture et de code source uniquement ; il ne s’agit pas d’une interface du produit Builder.
  • Le lien vers le package public est épinglé à son commit historique, car ce package est absent de l’instantané actuel de la branche principale.
  • Aucune exécution RAG hébergée, aucun appel de modèle ni aucun jeu de données client ne sont représentés.

https://github.com/AndriusPetrenas/QueryLexV6 · 401928a0d20107545673641e228a9869b1806c16 · /solutions/rag-builder

Archive overview

A RAG system is a chain of evidence decisions.

The archived package makes ingestion, chunking, indexing, retrieval, reranking, completion and evaluation boundaries inspectable. It is source architecture, not a hosted builder.

01Archived source

Python package pinned to a historical commit.

02Downloadable

The code can be inspected and downloaded from GitHub.

03Not hosted

No active ingestion, retrieval or model endpoint.

Detailed pipeline

Seven stages. Every boundary is inspectable.

Select a stage to inspect its input, output, technology, source path and evaluation implication.

Pinned source snapshot134e52c
Vue de l’archive

Un système RAG est une chaîne de décisions sur les preuves.

Le package archivé rend inspectables les frontières d’ingestion, de découpage, d’indexation, de recherche, de réordonnancement, de complétion et d’évaluation. C’est une architecture source, pas un builder hébergé.

01Source archivée

Package Python épinglé à un commit historique.

02Téléchargeable

Le code peut être inspecté et téléchargé depuis GitHub.

03Non hébergé

Aucun endpoint actif d’ingestion, de recherche ou de modèle.

Pipeline détaillé

Sept étapes. Chaque frontière est inspectable.

Sélectionnez une étape pour examiner son entrée, sa sortie, sa technologie, son fichier source et son implication pour l’évaluation.

Instantané de source épinglé134e52c
Every technique, explainedChaque technique, expliquée

Fourteen techniques — what each does, the problem it solves, and when to switch it on.

Quatorze techniques — ce que fait chacune, le problème qu’elle résout, et quand l’activer.

Costs, timings and accuracy figures are the published figures for this pipeline architecture, not fresh benchmarks of the archived package. Each technique names the file that implements it.

Les coûts, les temps et les gains de précision sont les chiffres publiés pour cette architecture de pipeline, et non de nouveaux benchmarks du package archivé. Chaque technique nomme le fichier qui l’implémente.

Phase 1 · Document processing

Phase 1 · Traitement des documents

7 techniques7 techniques
  1. Step 1Étape 1

    Text extraction & legal tokenization

    Regex-based parsing and legal tokenization

    Extraction du texte et tokenisation juridique

    Analyse par expressions régulières et tokenisation juridique

    What it does
    • Extracts raw text from PDF (PyPDF2/pdfplumber), DOCX (python-docx) and TXT files.
    • Applies legal tokenization: protects 100+ legal abbreviations from being split.
    • Protected examples: “Art.”, “Sec.”, “Corp.”, “Inc.”, “Ltd.”, “TFEU”, “GDPR”, “BGH”, “§”, “No.”, “v.”, “et al.”
    • Converts “Art. 101” → “Art__DOT__ 101” during chunking, then restores it.
    Ce que fait la technique
    • Extrait le texte brut des fichiers PDF (PyPDF2/pdfplumber), DOCX (python-docx) et TXT.
    • Applique une tokenisation juridique : plus de 100 abréviations juridiques sont protégées du découpage.
    • Exemples protégés : « Art. », « Sec. », « Corp. », « Inc. », « Ltd. », « TFUE », « RGPD », « BGH », « § », « n° », « c. », « et al. »
    • Convertit « Art. 101 » → « Art__DOT__ 101 » pendant le découpage, puis rétablit la forme d’origine.
    Problem it solves
    • Standard tokenizers split “Art. 101” into [“Art”, “.”, “101”] across chunk boundaries.
    • That breaks legal citations, so a search for “Article 101” fails to match “Art. 101”.
    • Legal documents use abbreviation patterns absent from standard NLP tokenizers.
    Le problème résolu
    • Les tokeniseurs standards découpent « Art. 101 » en [« Art », « . », « 101 »] de part et d’autre des chunks.
    • Les citations juridiques sont cassées : une recherche « Article 101 » ne trouve plus « Art. 101 ».
    • Les documents juridiques ont des schémas d’abréviation absents des tokeniseurs NLP standards.
    When to use it
    • Always active during ingestion.
    Quand l’utiliser
    • Toujours actif lors de l’ingestion.
    Cost
    Coût
    $0
    0 $
    Time
    Temps
    +2 ms per document
    +2 ms par document
    Accuracy
    Précision
    +15% on citation queries
    +15 % sur les requêtes de citation
    Implemented in Implémenté dans legal_tokenizer.pyScientific basis Base scientifique Adaptive RAG Pipeline for Legal Research
  2. Step 2Étape 2

    Semantic chunking

    256-token chunks with overlap

    Découpage sémantique

    Chunks de 256 tokens avec recouvrement

    What it does
    • Token-based splitting via tiktoken (cl100k_base).
    • Default: 256 tokens per chunk, 50 tokens of overlap (20%).
    • Model-aware sizing: Isaacus (512), Voyage/Cohere (384), OpenAI (256).
    • Structure-aware: prefers paragraph boundaries over mid-sentence cuts.
    • Metadata prefix: “Document: {file}, Page: {pg}, Section: {sec}”.
    Ce que fait la technique
    • Découpage par tokens via tiktoken (cl100k_base).
    • Par défaut : 256 tokens par chunk, 50 tokens de recouvrement (20 %).
    • Taille adaptée au modèle : Isaacus (512), Voyage/Cohere (384), OpenAI (256).
    • Respect de la structure : préfère les frontières de paragraphe aux coupes en milieu de phrase.
    • Préfixe de métadonnées : « Document : {fichier}, Page : {pg}, Section : {sec} ».
    Problem it solves
    • Character-based chunking cuts mid-word or mid-sentence and destroys meaning.
    • Fixed-size chunks ignore document structure (articles, sections, paragraphs).
    • Without overlap, the context at each boundary is lost for good.
    Le problème résolu
    • Le découpage par caractères coupe au milieu d’un mot ou d’une phrase et détruit le sens.
    • Les chunks de taille fixe ignorent la structure du document (articles, sections, paragraphes).
    • Sans recouvrement, le contexte aux frontières est définitivement perdu.
    When to use it
    • Standard strategy for all text-based documents.
    • Use when documents have a clear paragraph structure.
    • Optimal for legal texts where a concept fits within ~200–300 words.
    Quand l’utiliser
    • Stratégie standard pour tous les documents textuels.
    • À utiliser quand les documents ont une structure de paragraphes claire.
    • Optimal pour les textes juridiques où un concept tient en ~200–300 mots.
    Cost
    Coût
    $0
    0 $
    Time
    Temps
    +5 ms per 1,000 tokens
    +5 ms par 1 000 tokens
    Chunks per document
    Chunks par document
    ~20–100 depending on size
    ~20–100 selon la taille
    Implemented in Implémenté dans document_processor.pyScientific basis Base scientifique HiChunk: Evaluating & Enhancing RAG
  3. Step 3Étape 3OptionalOptionnel

    Metadata extraction

    Extracts jurisdiction, type and dates

    Extraction des métadonnées

    Extrait la juridiction, le type et les dates

    What it does
    • Sends the first 3,000 characters of the document to an LLM for classification.
    • Extracts structured metadata: document type, jurisdiction, practice area, date, parties, key provisions.
    • Falls back to regex heuristics if the LLM call fails.
    Ce que fait la technique
    • Envoie les 3 000 premiers caractères du document à un LLM pour classification.
    • Extrait des métadonnées structurées : type de document, juridiction, domaine, date, parties, dispositions clés.
    • Bascule sur des heuristiques par expressions régulières si l’appel au LLM échoue.
    Problem it solves
    • Users want to filter: “show me only EU antitrust regulations”.
    • Manual tagging does not scale once a corpus grows past a few hundred documents.
    • A filename alone does not capture document type or jurisdiction.
    Le problème résolu
    • Les utilisateurs veulent filtrer : « montre-moi seulement les règlements antitrust de l’UE ».
    • L’étiquetage manuel ne passe pas à l’échelle au-delà de quelques centaines de documents.
    • Le nom de fichier seul ne dit ni le type de document ni la juridiction.
    When to use it
    • Use when users need to filter results by jurisdiction or document type.
    • Ideal for mixed corpora (for example EU and US law together).
    • When an automated taxonomy is preferable to manual tagging.
    Quand l’utiliser
    • À utiliser quand les utilisateurs doivent filtrer par juridiction ou type de document.
    • Idéal pour les corpus mixtes (par exemple droit de l’UE et droit américain ensemble).
    • Quand une taxonomie automatique est préférable à l’étiquetage manuel.
    Cost
    Coût
    ~$0.005 per document
    ~0,005 $ par document
    Time
    Temps
    +800 ms per document
    +800 ms par document
    Filtering accuracy
    Précision du filtrage
    +5–15%
    +5–15 %
    Implemented in Implémenté dans metadata_extractor.pyScientific basis Base scientifique Ontology-Grounded RAG
  4. Step 4Étape 4OptionalOptionnel

    SAC — summary-augmented chunking

    Summary-augmented chunking

    SAC — découpage augmenté par résumé

    Summary-Augmented Chunking

    What it does
    • For each chunk, an LLM generates a two-to-three sentence contextual summary.
    • The summary captures document type, main topic, key concepts and position in the document.
    • The summary is prepended to the chunk before embedding.
    Ce que fait la technique
    • Pour chaque chunk, un LLM génère un résumé contextuel de deux à trois phrases.
    • Le résumé capture le type de document, le sujet principal, les concepts clés et la position dans le document.
    • Le résumé est ajouté en tête du chunk avant l’embedding.
    Problem it solves
    • Chunk 47 of 100 has no idea it comes from an “EU Merger Regulation”.
    • The query “EU merger control” will not match a chunk that only says “the undertakings shall…”.
    • Middle chunks become orphans, semantically disconnected from the document’s purpose.
    Le problème résolu
    • Le chunk 47 sur 100 n’a aucune idée qu’il provient d’un « règlement européen sur les concentrations ».
    • La requête « contrôle des concentrations UE » ne correspondra pas à un chunk qui dit seulement « les entreprises doivent… ».
    • Les chunks du milieu deviennent orphelins, sémantiquement coupés de l’objet du document.
    When to use it
    • Crucial for long, complex regulations where context is lost in the middle chunks.
    • Use when queries relate to the document globally (“what does this update say?”).
    • When higher accuracy is worth the extra processing cost.
    Quand l’utiliser
    • Crucial pour les règlements longs et complexes où le contexte se perd dans les chunks du milieu.
    • À utiliser quand les requêtes portent sur le document dans son ensemble (« que dit cette mise à jour ? »).
    • Quand un gain de précision justifie le coût de traitement supplémentaire.
    Cost
    Coût
    ~$0.001 per chunk
    ~0,001 $ par chunk
    Time
    Temps
    +500 ms per chunk
    +500 ms par chunk
    Retrieval accuracy
    Précision de la recherche
    +10–20%
    +10–20 %
    Implemented in Implémenté dans sac_generator.pyScientific basis Base scientifique Summary-Augmented Chunking (SAC)
  5. Step 5Étape 5

    Multi-provider embedding

    OpenAI / Cohere / Voyage / Isaacus

    Embeddings multi-fournisseurs

    OpenAI / Cohere / Voyage / Isaacus

    What it does
    • Converts a text chunk into a dense vector.
    • Supports multiple providers: OpenAI (1536 dim), Isaacus Legal (1792 dim), Voyage (1024 dim), Cohere (1024 dim).
    • Each chunk becomes a vector such as [0.023, -0.847, …].
    Ce que fait la technique
    • Convertit un chunk de texte en vecteur dense.
    • Prend en charge plusieurs fournisseurs : OpenAI (1536 dim), Isaacus Legal (1792 dim), Voyage (1024 dim), Cohere (1024 dim).
    • Chaque chunk devient un vecteur du type [0,023, -0,847, …].
    Problem it solves
    • Keyword search (BM25) only matches exact words: “automobile” ≠ “car”.
    • General embeddings miss legal nuance: “consideration” in contract law versus everyday use.
    • A single provider is a single point of failure.
    Le problème résolu
    • La recherche par mots-clés (BM25) ne trouve que les mots exacts : « automobile » ≠ « voiture ».
    • Les embeddings généralistes passent à côté de la nuance juridique : « consideration » en droit des contrats face à son sens courant.
    • Dépendre d’un seul fournisseur crée un point de défaillance unique.
    When to use it
    • Always required for semantic search.
    • Use Isaacus Legal for specialised legal terminology.
    • Use OpenAI for general-purpose versatility.
    Quand l’utiliser
    • Toujours nécessaire pour la recherche sémantique.
    • Utiliser Isaacus Legal pour la terminologie juridique spécialisée.
    • Utiliser OpenAI pour la polyvalence générale.
    Cost
    Coût
    $0.02–$0.35 per 1M tokens
    0,02–0,35 $ par million de tokens
    Time
    Temps
    ~50–200 ms per batch
    ~50–200 ms par lot
    Quality
    Qualité
    Foundation of retrieval
    Socle de la recherche
    Implemented in Implémenté dans embedding_service.pyScientific basis Base scientifique HetaRAG: Hybrid Deep RAG
  6. Step 6Étape 6OptionalOptionnel

    ColBERT sentence embeddings

    Sentence-level embeddings stored beside each chunk

    Embeddings de phrases ColBERT

    Embeddings au niveau de la phrase, stockés à côté de chaque chunk

    What it does
    • Splits each chunk into three to eight sentences.
    • Embeds each sentence separately, instead of one embedding for the whole chunk.
    • Stores the sentence embeddings alongside the chunk embedding.
    • At search time, MaxSim scoring takes MAX(similarity(query, sentence_i)) across the sentences.
    Ce que fait la technique
    • Découpe chaque chunk en trois à huit phrases.
    • Encode chaque phrase séparément, au lieu de produire un seul embedding pour tout le chunk.
    • Stocke les embeddings de phrases à côté de l’embedding du chunk.
    • Au moment de la recherche, le score MaxSim prend MAX(similarité(requête, phrase_i)) sur l’ensemble des phrases.
    Problem it solves
    • A single chunk embedding is an average of all its sentences, which dilutes specific matches.
    • A query about “fines” matches poorly against a chunk that is 80% about procedure.
    • Important specific information stays buried in irrelevant surrounding text.
    Le problème résolu
    • Un embedding unique par chunk est la moyenne de toutes ses phrases, ce qui dilue les correspondances précises.
    • Une requête sur les « amendes » correspond mal à un chunk consacré à 80 % à la procédure.
    • L’information précise reste noyée dans le texte environnant non pertinent.
    When to use it
    • Use for needle-in-a-haystack retrieval.
    • When users ask very specific questions buried in long paragraphs.
    • When storage space matters less than precision.
    Quand l’utiliser
    • À utiliser pour retrouver une aiguille dans une botte de foin.
    • Quand les utilisateurs posent des questions très précises noyées dans de longs paragraphes.
    • Quand l’espace de stockage compte moins que la précision.
    Cost
    Coût
    ~$0.002 per chunk
    ~0,002 $ par chunk
    Time
    Temps
    +100 ms per query (rerank)
    +100 ms par requête (réordonnancement)
    Precision
    Précision
    +5–15%
    +5–15 %
  7. Step 7Étape 7

    Vector storage (Supabase)

    Supabase pgvector

    Stockage vectoriel (Supabase)

    Supabase pgvector

    What it does
    • Stores chunks in PostgreSQL with the pgvector extension.
    • Multiple embedding columns for different dimensions: 1024, 1536, 1792.
    • Stores content, metadata (JSON), source, page, chunk index and sentence embeddings.
    Ce que fait la technique
    • Stocke les chunks dans PostgreSQL avec l’extension pgvector.
    • Plusieurs colonnes d’embeddings pour différentes dimensions : 1024, 1536, 1792.
    • Stocke le contenu, les métadonnées (JSON), la source, la page, l’index du chunk et les embeddings de phrases.
    Problem it solves
    • You need performant vector similarity search together with rich metadata filtering.
    • Proprietary vector databases are expensive and disconnected from application data.
    Le problème résolu
    • Il faut une recherche vectorielle performante et un filtrage riche sur les métadonnées.
    • Les bases vectorielles propriétaires sont coûteuses et déconnectées des données de l’application.
    When to use it
    • Always used, as the central knowledge base.
    Quand l’utiliser
    • Toujours utilisé, comme base de connaissances centrale.
    Storage
    Stockage
    ~1 KB per chunk plus vectors
    ~1 Ko par chunk, vecteurs en sus
    Query
    Requête
    <50 ms for 1M vectors
    <50 ms pour 1 million de vecteurs

Phase 2 · Query processing

Phase 2 · Traitement des requêtes

7 techniques7 techniques
  1. Step 1Étape 1OptionalOptionnel

    Query decomposition

    Break complex queries into focused sub-queries

    Décomposition de la requête

    Diviser les requêtes complexes en sous-requêtes ciblées

    What it does
    • Analyses query complexity with heuristics (word count, “and”/“or”, question form).
    • If complex, an LLM breaks it into two to four focused sub-queries.
    • Each sub-query searches independently.
    • Results are merged with Reciprocal Rank Fusion (RRF).
    Ce que fait la technique
    • Analyse la complexité de la requête à l’aide d’heuristiques (nombre de mots, « et »/« ou », forme interrogative).
    • Si elle est complexe, un LLM la divise en deux à quatre sous-requêtes ciblées.
    • Chaque sous-requête effectue sa propre recherche.
    • Les résultats sont fusionnés par Reciprocal Rank Fusion (RRF).
    Problem it solves
    • Complex queries carry several information needs at once.
    • One embedding cannot represent “EU fines” and “US fines” and “comparison” equally.
    • A user asking about several jurisdictions needs documents from each.
    • Long queries get diluted into vague embeddings.
    Le problème résolu
    • Les requêtes complexes portent plusieurs besoins d’information à la fois.
    • Un seul embedding ne peut représenter à égalité « amendes dans l’UE », « amendes aux États-Unis » et « comparaison ».
    • Un utilisateur qui interroge plusieurs juridictions a besoin de documents de chacune.
    • Les requêtes longues se diluent en embeddings vagues.
    When to use it
    • Use for multi-part questions (“compare X and Y”).
    • When queries are long and contain several distinct concepts.
    • Not recommended for simple keyword lookups: it adds latency.
    Quand l’utiliser
    • À utiliser pour les questions à plusieurs volets (« comparer X et Y »).
    • Quand les requêtes sont longues et contiennent plusieurs concepts distincts.
    • Déconseillé pour une simple recherche par mot-clé : cela ajoute de la latence.
    Cost
    Coût
    ~$0.002 per query
    ~0,002 $ par requête
    Time
    Temps
    +300 ms
    +300 ms
    Recall
    Rappel
    +15–25% on complex queries
    +15–25 % sur les requêtes complexes
  2. Step 2Étape 2OptionalOptionnel

    HyDE — hypothetical embeddings

    Hypothetical document embeddings

    HyDE — embeddings hypothétiques

    Hypothetical Document Embeddings

    What it does
    • An LLM generates a hypothetical document that would answer the query.
    • That hypothetical document is embedded instead of, or alongside, the query.
    • The hypothesis uses document-like vocabulary, so it matches indexed documents better.
    Ce que fait la technique
    • Un LLM génère un document hypothétique qui répondrait à la requête.
    • Ce document hypothétique est encodé à la place de la requête, ou en plus de celle-ci.
    • L’hypothèse emploie le vocabulaire d’un document, elle correspond donc mieux aux documents indexés.
    Problem it solves
    • Vocabulary mismatch: users ask questions, documents state facts.
    • “What are the fines?” (a question) versus “Fines shall not exceed…” (a statement).
    • Short queries produce sparse, uninformative embeddings.
    Le problème résolu
    • Décalage de vocabulaire : les utilisateurs posent des questions, les documents énoncent des faits.
    • « Quelles sont les amendes ? » (question) face à « Les amendes ne peuvent excéder… » (affirmation).
    • Les requêtes courtes produisent des embeddings pauvres et peu informatifs.
    When to use it
    • Use when queries are very short or abstract.
    • When there is a vocabulary gap between user questions and legal text.
    • Effective for concept search rather than keyword search.
    Quand l’utiliser
    • À utiliser quand les requêtes sont très courtes ou abstraites.
    • Quand il existe un écart de vocabulaire entre les questions et le texte juridique.
    • Efficace pour la recherche par concept plutôt que par mot-clé.
    Cost
    Coût
    ~$0.003 per query
    ~0,003 $ par requête
    Time
    Temps
    +400 ms
    +400 ms
    Semantic matching
    Correspondance sémantique
    +10–30%
    +10–30 %
    Implemented in Implémenté dans hyde.py
  3. Step 3Étape 3

    Hybrid search

    Vector + keyword (BM25) with RRF

    Recherche hybride

    Vectoriel + mots-clés (BM25) avec RRF

    What it does
    • Runs two searches in parallel: vector search (semantic) and BM25 keyword search (exact).
    • Merges the results with Reciprocal Rank Fusion (RRF).
    Ce que fait la technique
    • Lance deux recherches en parallèle : vectorielle (sémantique) et BM25 par mots-clés (exacte).
    • Fusionne les résultats par Reciprocal Rank Fusion (RRF).
    Problem it solves
    • Vector search: “Article 101” might match “Article 102”, because they are semantically similar.
    • Keyword search: “car” will not match “automobile”, because there is no semantic understanding.
    • Legal citations need an exact match; concepts need a semantic one.
    Le problème résolu
    • Recherche vectorielle : « Article 101 » peut correspondre à « Article 102 », car les deux sont sémantiquement proches.
    • Recherche par mots-clés : « voiture » ne correspond pas à « automobile », faute de compréhension sémantique.
    • Les citations juridiques exigent une correspondance exacte ; les concepts, une correspondance sémantique.
    When to use it
    • Always recommended for legal search.
    • Essential when users search for specific entities: case IDs, article numbers.
    • Combines the precision of keywords with the recall of semantics.
    Quand l’utiliser
    • Toujours recommandé pour la recherche juridique.
    • Indispensable quand les utilisateurs cherchent des entités précises : numéros d’affaire, numéros d’article.
    • Combine la précision des mots-clés et le rappel de la sémantique.
    Cost
    Coût
    $0 (local)
    0 $ (local)
    Time
    Temps
    +50 ms
    +50 ms
    Recall
    Rappel
    +20–30%
    +20–30 %
    Implemented in Implémenté dans legal_filters.pyScientific basis Base scientifique Blended RAG: Semantic + Hybrid
  4. Step 4Étape 4OptionalOptionnel

    ColBERT re-ranking

    MaxSim scoring

    Réordonnancement ColBERT

    Score MaxSim

    What it does
    • Takes the top N candidates from hybrid search.
    • Computes MaxSim: for each stored sentence, the similarity to the query.
    • The ColBERT score is the maximum sentence similarity.
    • Re-ranks the candidates by that score.
    Ce que fait la technique
    • Reprend les N meilleurs candidats de la recherche hybride.
    • Calcule MaxSim : pour chaque phrase stockée, la similarité avec la requête.
    • Le score ColBERT est la plus élevée de ces similarités.
    • Réordonne les candidats selon ce score.
    Problem it solves
    • A single chunk embedding is an average.
    • A query about “fines” matches poorly against a chunk that is 80% about procedure.
    • You need to find the exact sentence inside 256 tokens.
    Le problème résolu
    • Un embedding unique par chunk est une moyenne.
    • Une requête sur les « amendes » correspond mal à un chunk consacré à 80 % à la procédure.
    • Il faut trouver la phrase exacte à l’intérieur de 256 tokens.
    When to use it
    • Use when it was configured in phase 1: it requires sentence embeddings.
    • When users need to pinpoint exact sentences or clauses.
    • Ideal for fact-checking applications.
    Quand l’utiliser
    • À utiliser si l’option a été activée en phase 1 : elle exige des embeddings de phrases.
    • Quand les utilisateurs doivent localiser une phrase ou une clause exacte.
    • Idéal pour les usages de vérification des faits.
    Cost
    Coût
    $0 (pre-computed)
    0 $ (précalculé)
    Time
    Temps
    +100 ms
    +100 ms
    Precision
    Précision
    +5–15%
    +5–15 %
  5. Step 5Étape 5OptionalOptionnel

    Cross-encoder re-ranking

    Deep relevance scoring

    Réordonnancement par cross-encoder

    Score de pertinence approfondi

    What it does
    • Takes the top candidates from the previous stages.
    • Uses a cross-encoder model (ms-marco-MiniLM-L-6-v2) to process query and document together.
    • Outputs a relevance score from 0 to 1 for each pair.
    • Re-ranks by that score.
    Ce que fait la technique
    • Reprend les meilleurs candidats des étapes précédentes.
    • Utilise un modèle cross-encoder (ms-marco-MiniLM-L-6-v2) qui traite la requête et le document ensemble.
    • Produit un score de pertinence de 0 à 1 pour chaque paire.
    • Réordonne selon ce score.
    Problem it solves
    • Bi-encoders encode query and document independently, so they miss interaction patterns.
    • Cross-encoders are too slow for initial retrieval: they must compare every document.
    • Bi-encoders struggle with subtle negation and with the direction of a relationship.
    Le problème résolu
    • Les bi-encoders encodent la requête et le document séparément et passent à côté des schémas d’interaction.
    • Les cross-encoders sont trop lents pour la recherche initiale : ils doivent comparer chaque document.
    • Les bi-encoders peinent sur la négation subtile et sur le sens d’une relation.
    When to use it
    • Use to sort the final top ten for the highest possible relevance.
    • When nuances such as negation (“not liable”) are critical.
    • Runs locally, which avoids external API latency and cost.
    Quand l’utiliser
    • À utiliser pour ordonner les dix premiers résultats avec la meilleure pertinence possible.
    • Quand des nuances comme la négation (« non responsable ») sont déterminantes.
    • Fonctionne en local, ce qui évite la latence et le coût d’une API externe.
    Cost
    Coût
    $0 (local)
    0 $ (local)
    Time
    Temps
    +50–100 ms
    +50–100 ms
    Precision
    Précision
    +15–25%
    +15–25 %
  6. Step 6Étape 6OptionalOptionnel

    Agentic RAG

    Iterative search and refinement

    RAG agentique

    Recherche et affinage itératifs

    What it does
    • An LLM agent controls the search process with iterative refinement.
    • Loop: plan → search → evaluate → refine, up to three iterations.
    • Self-evaluation: is the retrieved context sufficient to answer?
    Ce que fait la technique
    • Un agent LLM pilote la recherche avec un affinage itératif.
    • Boucle : planifier → chercher → évaluer → affiner, jusqu’à trois itérations.
    • Auto-évaluation : le contexte retrouvé suffit-il à répondre ?
    Problem it solves
    • The first search attempt may miss relevant documents.
    • The user does not know the right keywords to search for.
    • Complex legal topics span several document types and vocabularies.
    Le problème résolu
    • La première recherche peut manquer des documents pertinents.
    • L’utilisateur ne connaît pas les bons mots-clés.
    • Les sujets juridiques complexes recouvrent plusieurs types de documents et plusieurs vocabulaires.
    When to use it
    • Use for open-ended research questions (“what is the case law on X?”).
    • When the user is unsure of the exact terminology.
    • For comprehensive reports, where thoroughness matters more than speed.
    Quand l’utiliser
    • À utiliser pour les questions de recherche ouvertes (« quelle est la jurisprudence sur X ? »).
    • Quand l’utilisateur n’est pas sûr de la terminologie exacte.
    • Pour les rapports exhaustifs, où la rigueur importe plus que la vitesse.
    Cost
    Coût
    ~$0.01 per query
    ~0,01 $ par requête
    Time
    Temps
    +1–3 s
    +1–3 s
    Complex query improvement
    Gain sur requêtes complexes
    +20–40%
    +20–40 %
  7. Step 7Étape 7

    Answer generation

    LLM with citation grounding

    Génération de la réponse

    LLM avec ancrage des citations

    What it does
    • Builds a prompt from system instructions (a legal role) plus the retrieved chunks.
    • The LLM generates an answer grounded in the retrieved documents.
    • Includes source citations for verification.
    Ce que fait la technique
    • Construit un prompt à partir d’instructions système (un rôle de juriste) et des chunks retrouvés.
    • Le LLM génère une réponse ancrée dans les documents retrouvés.
    • Inclut les citations des sources pour vérification.
    Problem it solves
    • Pure LLMs hallucinate facts and references.
    • Users need to be able to verify claims.
    Le problème résolu
    • Les LLM seuls hallucinent des faits et des références.
    • Les utilisateurs doivent pouvoir vérifier les affirmations.
    When to use it
    • The final destination for all chat-based interactions.
    • When users need a synthesised answer, not a list of links.
    • To produce draft responses, summaries or analyses.
    Quand l’utiliser
    • La destination finale de toute interaction conversationnelle.
    • Quand les utilisateurs veulent une réponse synthétisée, pas une liste de liens.
    • Pour produire des projets de réponse, des synthèses ou des analyses.
    Cost
    Coût
    ~$0.01–0.05 per answer
    ~0,01–0,05 $ par réponse
    Quality
    Qualité
    Grounded, verifiable answers
    Réponses ancrées et vérifiables

Cost and performance summary

Coûts et performances

Document processing

Traitement des documents

Legal tokenization
Tokenisation juridique
$0
0 $
Semantic chunking
Découpage sémantique
$0
0 $
Metadata extraction
Extraction des métadonnées
$0.005 / doc
0,005 $ / doc
SAC summaries
Résumés SAC
$0.001 / chunk
0,001 $ / chunk
Total (100 pages)
Total (100 pages)
~$1.21
~1,21 $

Query processing

Traitement des requêtes

Query decomposition
Décomposition de la requête
$0.002
0,002 $
HyDE
HyDE
$0.003
0,003 $
Agentic loop (3×)
Boucle agentique (3×)
$0.01
0,01 $
Answer generation
Génération de la réponse
$0.01
0,01 $
Full complexity
Complexité maximale
~$0.025 / query
~0,025 $ / requête

Real-world scenario — a 10-page regulation

  • 10 pages, roughly 5,000 words.
  • ~50 chunks of 256 tokens each.
  • Goal: analytical search — “what are the penalties?”

Cas réel — un règlement de 10 pages

  • 10 pages, environ 5 000 mots.
  • ~50 chunks de 256 tokens chacun.
  • Objectif : recherche analytique — « quelles sont les sanctions ? »
Basic (embedding only)
Base (embedding seul)
~$0.001 (2 s)
~0,001 $ (2 s)
+ metadata extraction
+ extraction des métadonnées
~$0.006 (3 s)
~0,006 $ (3 s)
+ SAC summaries
+ résumés SAC
~$0.050 (30 s)
~0,050 $ (30 s)
+ ColBERT re-ranking
+ réordonnancement ColBERT
~$0.100 (20 s)
~0,100 $ (20 s)
Full pipeline total
Total du pipeline complet
~$0.16 (45 s)
~0,16 $ (45 s)

Chunking — default parameters

Découpage — paramètres par défaut

ParameterValuePurpose
ParamètreValeurRôle
chunk_size256 tokensTarget size (~1,024 characters)
chunk_size256 tokensTaille cible (~1 024 caractères)
overlap50 tokensContext overlap (20%)
overlap50 tokensRecouvrement de contexte (20 %)
min_chunk25 tokensSkip small chunks
min_chunk25 tokensIgnorer les chunks trop courts

Other functionality can be added if you need it. Email andrius@querylex.com and we will code it.D’autres fonctionnalités peuvent être ajoutées si vous en avez besoin. Écrivez à andrius@querylex.com et nous les coderons.

Excluded on purpose, and why

Ce que nous excluons volontairement, et pourquoi

Knowledge graphs

Graphes de connaissances

Not implementedNon implémenté

No — not at 4k chunks, and not even at 40k.

  • Knowledge graphs only pay off on corpora orders of magnitude larger than this one.
  • And only when the same entities recur across a large share of those documents.
  • At this scale, extraction costs dominate.
  • The graph itself would be tiny.
  • Traversal adds milliseconds and no benefit.
  • A graph database adds roughly $200 a month for no measurable gain.

Non — ni à 4 000 chunks, ni même à 40 000.

  • Les graphes de connaissances ne deviennent rentables qu’à partir de dizaines de milliers de documents.
  • Et seulement quand les mêmes entités se répètent dans des milliers d’entre eux.
  • À cette échelle, le coût d’extraction domine.
  • Le graphe lui-même serait minuscule.
  • Le parcours du graphe ajoute des millisecondes, sans aucun bénéfice.
  • Une base de graphes coûte environ 200 $ par mois sans aucun gain mesurable.

GraphRAG

GraphRAG

Not implementedNon implémenté

Absolutely not — not before 100k documents.

  • GraphRAG is designed for large corpora, millions of tokens, where themes must be discovered rather than retrieved.
  • At this scale, ingestion would cost too much.
  • Community detection would cluster trivially.
  • Hours would go into summaries that add no value.
  • Latency and cost become unacceptable.

Absolument pas — pas avant 100 000 documents.

  • GraphRAG est conçu pour de grands corpus, des millions de tokens, où les thèmes doivent être découverts plutôt que retrouvés.
  • À cette échelle, l’ingestion coûterait trop cher.
  • La détection de communautés produirait des regroupements triviaux.
  • Des heures seraient consacrées à des résumés sans valeur ajoutée.
  • La latence et le coût deviendraient inacceptables.
Evidence boundaryFrontière de preuve

The architecture image and the downloadable source prove different things.

L’image d’architecture et la source téléchargeable prouvent des choses différentes.

01 / EVIDENCE

Architecture explainer

Explication d’architecture

The manifested image captures this site’s native schema at source commit 401928a. It is architecture and source-code proof, never a builder interface.

L’image du manifeste capture le schéma natif de ce site au commit 401928a. C’est une preuve d’architecture et de code source, jamais une interface du builder.

02 / SOURCE

Archived Python package

Package Python archivé

The pinned rag-pipeline tree proves downloadable implementation source at 134e52c. It does not prove hosting, uptime, answer quality or a live product.

L’arborescence rag-pipeline épinglée prouve une source d’implémentation téléchargeable au commit 134e52c. Elle ne prouve ni hébergement, ni disponibilité, ni qualité des réponses, ni produit actif.

View on GitHubVoir sur GitHub
Technical depthProfondeur technique

Seven files ground the complete architecture path.

Sept fichiers ancrent le parcours architectural complet.

Each link opens the exact file at the verified historical commit, not the moving default branch.

Chaque lien ouvre le fichier exact au commit historique vérifié, pas sur la branche par défaut changeante.

  1. 01
    document_processor.py

    Coordinates PDF processing, token-bounded chunking, indexing and candidate retrieval.

    Coordonne le traitement PDF, la segmentation bornée en jetons, l’indexation et la recherche de candidats.

    Open sourceOuvrir la source
  2. 02
    embedding_service.py

    Exposes the configurable embedding boundary used before vector storage.

    Expose la frontière d’embedding configurable utilisée avant le stockage vectoriel.

    Open sourceOuvrir la source
  3. 03
    supabase_client.py

    Stores and retrieves vectors with document metadata through dimension-specific pgvector paths.

    Stocke et retrouve les vecteurs avec leurs métadonnées documentaires par des voies pgvector propres à chaque dimension.

    Open sourceOuvrir la source
  4. 04
    legal_filters.py

    Resolves legal-source selections into metadata conditions for filtered retrieval.

    Convertit les sélections de sources juridiques en conditions de métadonnées pour la recherche filtrée.

    Open sourceOuvrir la source
  5. 05
    reranker.py

    Scores query–document pairs and returns a shorter ordered candidate set.

    Note les paires requête–document et renvoie un ensemble candidat ordonné plus court.

    Open sourceOuvrir la source
  6. 06
    llm_utils.py

    Returns raw completion text only; citation mapping is not implemented here.

    Renvoie uniquement un texte de complétion brute ; la correspondance des citations n’y est pas implémentée.

    Open sourceOuvrir la source
  7. 07
    agentic_rag.py

    Contains the optional retrieval-sufficiency prompt, bounded iteration and search history.

    Contient le prompt facultatif de suffisance de recherche, l’itération bornée et l’historique.

    Open sourceOuvrir la source
Archive boundary

A toolkit is not a production knowledge system.

The archive has no active hosting, identity, tenant isolation, document-retention service, monitoring layer or managed model credentials.

01

Retrieval evaluation

The optional agentic loop prompts for retrieval sufficiency. It is not an end-to-end benchmark.

02

Citation boundary

Source metadata is retained, but the package supplies no answer assembler or citation renderer.

03

Human review

A cited RAG response remains an information-retrieval output. Legal authority, currency, completeness and application require professional review.

The excluded operating layer is substantial.

  • There is no hosted ingestion, indexing or retrieval endpoint.
  • Parsing and extraction errors can propagate into every later stage.
  • The optional evaluator checks retrieval sufficiency, not legal correctness or end-to-end answer quality.
  • The package does not include an answer assembler, citation renderer or human-review workflow.
Frontière de l’archive

Une boîte à outils n’est pas un système de connaissance en production.

L’archive ne comprend ni hébergement actif, ni identité, ni isolation tenant, ni service de rétention, ni supervision, ni identifiants de modèles gérés.

01

Évaluation de la recherche

La boucle agentic facultative évalue la suffisance des résultats à partir d’un prompt. Ce n’est pas un benchmark de bout en bout.

02

Frontière des citations

Les métadonnées de source sont conservées, mais le package ne fournit ni assembleur de réponse ni moteur d’affichage des citations.

03

Revue humaine

Une réponse RAG citée reste une sortie de recherche. Autorité, actualité, exhaustivité et application exigent une revue professionnelle.

La couche opérationnelle exclue est importante.

  • Aucun endpoint hébergé d’ingestion, d’indexation ou de recherche.
  • Les erreurs d’analyse et d’extraction peuvent se propager à chaque étape suivante.
  • L’évaluateur facultatif vérifie la suffisance de la recherche, pas la correction juridique ni la qualité de bout en bout.
  • Le package ne comprend ni assembleur de réponse, ni moteur d’affichage des citations, ni workflow de revue humaine.
Next step

Inspect the archived source before you build around its outputs.

The pinned package is public and downloadable. QueryLex can discuss the archive or a governed retrieval product built around your sources.

View on GitHubDiscuss the archive
Prochaine étape

Inspectez la source archivée avant de construire autour de ses sorties.

Le package épinglé est public et téléchargeable. QueryLex peut discuter de l’archive ou d’un produit de recherche gouverné construit autour de vos sources.

Voir sur GitHubDiscuter de l’archive