Una ricevuta di retrieval è il JSON che la query ha scritto

Perché conta

Se non posso rileggere il risultato di una query, mi resta una storia. Mi serve un JSON che tenga insieme la query, i file, gli score, gli snippet e gli intervalli di righe.

Quel JSON è già pubblico. RAGFS lo documenta nella User Guide. La scheda ragfs indica il repository e la documentazione. Leggo quelle pagine. Non aggiungo un cliente, un'azienda o un benchmark.

La decisione di interfaccia sta in Perché ho dato agli agenti un filesystem invece di un'altra API. Qui mi interessa la ricevuta: che cosa scrive una query, e che cosa quella scrittura non è.

Che cosa registra la ricevuta pubblica

La User Guide mostra il comando di query e la forma JSON che stampa:

ragfs query ./src "error handling implementation" -f json

{
  "query": "error handling implementation",
  "results": [
    {
      "file": "src/lib.rs",
      "score": 0.847,
      "content": "Handle errors gracefully by...",
      "lines": "45:52"
    }
  ]
}

Come ricevuta di retrieval tengo solo questi cinque campi:

1. query: la stringa che ho chiesto.
2. file: il percorso restituito.
3. score: lo score stampato per quel risultato.
4. content: lo snippet restituito.
5. lines: l'intervallo di righe indicato.

La guida stampa anche una forma testo con gli stessi fatti: query, file, score, righe, snippet. Conservo il JSON perché uno script può leggerlo. Il sito di documentazione elenca query accanto a index, mount e status. La hybrid search è il comportamento predefinito documentato. Non lo uso come prova di qualità.

Sul mount la ricerca usa ancora un modello di embedding locale e conserva i vettori in LanceDB. La prima esecuzione scarica thenlper/gte-small. Le query successive usano quel modello. L'ho già scritto nell'articolo sul filesystem. Qui la ricevuta è il JSON, non il mount.

Che cosa non sono i numeri di esempio

Lo 0.847 è l'esempio della guida. Lo è anche il secondo score in forma testo, 0.812. Servono a mostrare il campo. Non sono un'esecuzione che ho misurato, e non sono un benchmark di qualità del retrieval.

Non ho pubblicato un benchmark di qualità o di scala per questa configurazione. L'articolo sul filesystem lo dice già. Non ne invento uno qui.

ragfs status --format json è un oggetto diverso: percorso, numero di file, numero di chunk, dimensione dell'indice, ultimo aggiornamento. La User Guide mostra anche un esempio di quell'oggetto. Quei conteggi sono testo di esempio della guida. Non sono un corpus che ho misurato per questa pagina.

Che cosa non pretendo

Una ricevuta dice che cosa ha restituito il comando. Non dice che il passaggio fosse quello giusto. RAG: chunking e re-ranking prima degli embedding resta l'ordine diagnostico quando il retrieval è debole: misurare, poi esaminare chunking e ranking prima di cambiare il modello di embedding.

Non dico che un cliente abbia usato questo JSON, né che un'azienda abbia adottato RAGFS. Non cito uno score privato. Se una frase non sta nel progetto pubblico, nella User Guide, nel sito di documentazione o in una ricevuta già presente su questo sito, la lascio fuori.

"Fidati, il contesto era pertinente" non è una ricevuta. Il JSON della query sì.

FAQ

Che cosa conta come ricevuta di retrieval RAGFS?

Il JSON della query: la stringa della query, e per ogni risultato il file, lo score, il content e l'intervallo di righe. La User Guide documenta quella forma.

Gli score 0.847 e 0.812 sono un benchmark pubblicato?

No. Sono i numeri di esempio della User Guide. Non ho pubblicato un benchmark di qualità o di scala del retrieval per questa configurazione.

Conservare il JSON prova che il hit fosse pertinente?

No. Il JSON registra che cosa ha restituito il comando. La pertinenza richiede ancora una valutazione. Uso l'ordine diagnostico di RAG in produzione quando il retrieval è debole.

Dov'è la ricevuta pubblica?

La forma query della User Guide, il repository e la documentazione. La scheda ragfs è l'indice pubblico.