Du PDF au prompt : ce que change ragnar pour le RAG en entreprise
Le retrieval-augmented generation (RAG) consiste à ancrer les réponses d'un LLM sur des documents internes plutôt que sur sa seule mémoire d'entraînement. Jusqu'ici, en entreprise, ce chantier se faisait presque toujours en Python avec LangChain ou LlamaIndex, et les équipes R devaient soit sortir de leur écosystème, soit bricoler des solutions ad hoc autour de requêtes HTTP vers une base vectorielle externe.
ragnar change cette donne en proposant un pipeline complet et idiomatique R : découpage de documents (chunking), génération d'embeddings, stockage vectoriel local via DuckDB, et récupération hybride combinant recherche sémantique et recherche par mots-clés. La version récente élargit le choix de fournisseurs d'embeddings et surtout permet à ragnar_retrieve() d'accepter plusieurs requêtes en une seule fois, ce qui simplifie l'écriture de pipelines qui reformulent une question utilisateur sous plusieurs angles avant de chercher.
Concrètement, un data scientist peut aujourd'hui ingérer un corpus de documentation interne, de rapports PDF ou de pages wiki, construire un index vectoriel stocké dans un fichier DuckDB versionnable, puis brancher ce magasin sur ellmer pour interroger les documents en langage naturel. Le tout tient dans un script R, sans microservice Python à maintenir, ce qui compte pour les équipes qui doivent livrer un prototype en quelques jours et le faire auditer par une DSI.
La bonne pratique consiste à séparer clairement l'étape d'ingestion, lancée en batch ou en CI, de l'étape de requête, exposée dans une app Shiny ou une API plumber. Le chunking reste le paramètre le plus sensible : trop fin, il casse le contexte ; trop large, il dilue la pertinence et gonfle les coûts de tokens. Il n'existe pas de réglage universel, il faut tester sur un échantillon de questions représentatives du métier.
Les limites sont réelles. ragnar est jeune comparé à son équivalent Python, l'écosystème de connecteurs est plus restreint, et le passage à l'échelle sur des millions de documents demandera probablement un backend vectoriel plus robuste que DuckDB. Pour des corpus de quelques milliers à quelques dizaines de milliers de documents, ce qui couvre la majorité des cas d'usage en entreprise, c'est largement suffisant.
library(ragnar)
store <- ragnar_store_create(
"docs_entreprise.duckdb",
embed = function(x) ragnar_embed_openai(x, model = "text-embedding-3-small")
)
chemins <- list.files("docs", pattern = "\\.pdf$", full.names = TRUE)
for (f in chemins) {
texte <- ragnar_read_document(f)
morceaux <- ragnar_chunk(texte, size = 800, overlap = 100)
ragnar_store_insert(store, morceaux)
}
ragnar_store_build_index(store)
resultats <- ragnar_retrieve(
store,
query = c("politique de remboursement", "conditions de remboursement client"),
top_k = 5
)
print(resultats)Le script ingère des PDF, les découpe en chunks, construit un index vectoriel DuckDB, puis interroge le store avec deux reformulations de la même question pour maximiser le rappel.
ragnar est le chaînon qui manquait pour faire du RAG sérieux sans quitter R : simple à démarrer, honnête sur ses limites de passage à l'échelle. À adopter pour les cas d'usage internes avant de considérer une architecture plus lourde.
→ Pour qui : Data scientists et développeurs Shiny qui veulent brancher un assistant IA sur une base documentaire interne sans dépendre d'un stack Python.
LES BRÈVES
Jarl, un linter R pensé pour la vitesse
Jarl propose une analyse statique du code R nettement plus rapide que lintr sur de gros projets, grâce à une implémentation en Rust. Pour une équipe qui exécute ses linters en CI à chaque commit, le gain de temps devient tangible sur un monorepo Shiny de plusieurs milliers de lignes.
Source : rweekly.org ↗dplyr enrichit sa famille de verbes de recodage
dplyr 1.2.0 introduit filter_out() comme complément naturel de filter(), accompagné de when_any() et when_all(), ainsi que recode_values() et replace_when() qui étendent les possibilités de case_when(). Ces ajouts, issus du processus communautaire des tidyups, évitent des constructions imbriquées fragiles pour des recodages métier courants.
Source : tidyverse.org ↗R-universe muscle son infrastructure de distribution
R-universe gagne des cartes de prévisualisation automatiques pour chaque package, un support de PACKAGES.rds réimplémenté en JavaScript, et une compression zstd plus rapide que CRAN sur macOS et Windows. Pour une équipe qui distribue des packages internes via r-universe, c'est une infrastructure qui se rapproche du confort de CRAN sans ses délais de publication.
Source : ropensci.org ↗LE TIP R DU JOUR
Construire une chaîne de caractères sans se perdre dans les guillemets
Quand un texte contient à la fois des apostrophes et des guillemets doubles, noquote() ou le choix du bon délimiteur évitent les échappements illisibles. R base permet aussi d'utiliser des guillemets bruts depuis R 4.0, ce qui simplifie l'écriture de regex ou de chemins Windows.
chemin <- r"(C:\Users\nom\Documents\rapport.docx)" cat(chemin) phrase <- r"(Il a dit : "c'est prêt")" cat(phrase)
SOURCES
- https://rweekly.org/2026-W36.html
- https://ropensci.org/blog/2026/06/07/r-universe-updates/
- https://tidyverse.org/blog/2026/02/dplyr-1-2-0/
- https://tidyverse.org/blog/2026/01/ragnar-0-3-0/
VOUS CODEZ EN R ?
Nous formons vos équipes à R, Shiny et l'IA, et industrialisons vos apps et modèles.