Idea principale

Un motore di ricerca vettoriale collegato a un repository di codice risponde bene a «dov'è scritta la regola che impedisce di modificare un elemento annullato?». Riporta i frammenti più vicini alla domanda, anche quelli che non ne usano nemmeno una parola, e lo fa bene tanto in una grande massa documentale quanto in un repository voluminoso.

Ritrova. Non si sposta. Eppure la domanda successiva è quasi sempre una domanda di vicinato: quale modulo chiama questo, quale altra regola riguarda lo stesso oggetto, quale evento ne scatena quello appena letto, quale schermata espone questo comportamento. Il motore non risponde, e non è un problema di taratura: la sua metrica è la vicinanza di significato tra un frammento e la domanda posta, mai la relazione tra due elementi del corpus.

Due capacità coprono questo spostamento, e non si somigliano. Un grafo semantico collega esplicitamente concetti, moduli ed eventi, e permette di passare da un nodo ai suoi vicini dichiarati. Percorrere il filesystem — elencare la directory in cui si è trovato il frammento, aprire i file accanto, leggere la struttura locale — è più rudimentale e spesso più efficace, perché l'albero delle directory contiene già una parte della relazione senza che nessuno abbia dovuto dichiararla.

Un sistema costruito sulla sola ricerca dà quindi risposte esatte su ciò che si è saputo chiedere, e mute su ciò che stava proprio lì accanto.

Perché è importante

Spiega un fallimento frequente: collegare un modello a un repository Git con un indice vettoriale e constatare che le risposte restano superficiali. Il problema non è la qualità della ricerca, è che delle due capacità ne è presente una sola.

Offre anche un criterio di valutazione che non riguarda il primo risultato. Un sistema per interrogare il codice non si giudica dalla pertinenza del frammento che riporta, ma da ciò che sa fare dopo: arrivare a ciò che chi pone la domanda non sapeva di dover chiedere.

Sfumature e limiti

La distinzione non è una gerarchia. Su un corpus piccolo o molto omogeneo ritrovare basta: i vicini sono nello stesso file, e lo spostamento avviene leggendo.

E spostarsi non sostituisce mai ritrovare. Un grafo senza punto d'ingresso non serve a niente; è la ricerca a fornire il nodo di partenza, e un ingresso sbagliato fa esplorare un vicinato che non ha nulla a che vedere con la domanda.

Infine, le due capacità non invecchiano allo stesso modo. Un albero di directory è sempre aggiornato, perché è il repository stesso; un grafo di relazioni dichiarate è un artefatto in più, che diverge appena il codice cambia senza che il grafo venga ricostruito.

Domande aperte

• Che cosa determina il punto di arresto di un percorso di vicinato — quanti salti prima che il contesto riportato smetta di chiarire la domanda e cominci a sommergerla?
• Su un repository che cambia ogni giorno, a partire da quando ricostruire un grafo di relazioni costa più di quanto faccia guadagnare rispetto a un semplice percorso tra le directory?