Come costruire raccomandazioni di articoli utilizzando solo Jina Reranker API

Abbiamo introdotto l'API Reranker due settimane fa, affermandola come una soluzione leader per il reranking sul mercato. Jina Reranker supera le baseline più popolari in vari benchmark, dimostrando un significativo aumento fino al +33% nel tasso di successo rispetto ai risultati BM25. Mentre le prestazioni sono impressionanti, ciò che mi entusiasma davvero è il potenziale dell'API Reranker. La sua interfaccia semplice permette l'input di una lista query-doc e restituisce direttamente i risultati top-k riordinati. Questo significa che, in teoria, si potrebbe costruire un sistema di ricerca o raccomandazione utilizzando solamente il Reranker—eliminando la necessità di BM25, embedding, database vettoriali o qualsiasi pipeline, ottenendo così una funzionalità end-to-end.

Questo concetto mi ha intrigato così tanto che mi sono sentito spinto a sperimentarlo. Quindi ecco qua: ora navigando su qualsiasi pagina di news del nostro sito web, come quella che stai leggendo attualmente, premi il tasto @ e clicca sul pulsante "get top 5 related articles", riceverai i cinque articoli più pertinenti a quello corrente in circa 5 secondi, utilizzando il modello jina-reranker-v1 (leggermente più lungo per il modello jina-colbert-v1). Tutti i calcoli vengono eseguiti online e gestiti interamente dall'API Reranker. Di seguito un video dimostrativo del suo funzionamento:

tagImplementazione

L'implementazione è molto semplice: per trovare gli articoli più correlati a un dato articolo su jina.ai/news/, utilizziamo l'articolo attualmente in lettura come query e tutti gli altri 230+ articoli (usando il loro testo completo!) sul nostro sito di news come documenti, escludendo ovviamente quello corrente. Quindi inviamo questo $(q, d_1, d_2, \cdots, d_{230})$ come payload all'API Reranker. Una volta ricevuta la risposta, utilizziamo l'indice dei documenti ordinato per visualizzare i risultati. Quindi, il codice sottostante è il seguente:

const getRecommendedArticles = async () => {
  
  const query = `${currentNews.title} ${currentNews.excerpt}`;
  const docs = newsStore.allBlogs.filter((item) => item.slug !== currentNews.slug);
  
  const data = {
    model: modelName,
    query: query,
    documents: docs,
    top_n: 5,
  }

  const rerankUrl = 'https://api.jina.ai/v1/rerank';
  const headers = {
    'Content-Type': 'application/json',
    Authorization: `Bearer ${apiKey}`,
  };
  const modelName = 'jina-reranker-v1-base-en';
  
  const res = await fetch(rerankUrl, {
    method: 'POST',
    headers: headers,
    body: JSON.stringify(data),
  });

  const resp = await res.json();

  const topKList = resp.results.map((item) => {
    return docs[item.index];
  });

  console.log(topKList);
}
Copy

Reranker API

Maximize the search relevancy and RAG accuracy at ease

E così, vedrai i risultati, che sono abbastanza promettenti per una prima iterazione, soprattutto considerando che il processo di implementazione richiede circa 10 minuti.

Mentre i lettori potrebbero avere preoccupazioni riguardo questa implementazione, alcune critiche potrebbero essere eccessive, mentre altre potrebbero essere valide:

• Le preoccupazioni riguardo testi troppo lunghi e la necessità di chunking potrebbero essere eccessive: il modello jina-reranker-v1 può elaborare query fino a 512 di lunghezza e documenti di lunghezza arbitraria, mentre il modello jina-colbert-v1 può gestire fino a 8192 sia per le query che per i documenti. Pertanto, inserire il testo completo nell'API Reranker è probabilmente non necessario. Entrambi i modelli gestiscono efficientemente i contesti lunghi, quindi non c'è motivo di preoccuparsi. Il chunking, sebbene sia forse l'aspetto più complicato ed euristico della pipeline embedding-vector-search-rerank, è meno problematico qui. Tuttavia, contesti più lunghi assumono più token, cosa che i nostri utenti a pagamento dell'API potrebbero dover considerare. In questo esempio, poiché utilizziamo il testo completo di tutti i 233 articoli, una query di rerank costa oltre 300K token.
• L'impatto dei dati grezzi rispetto a quelli puliti sulla qualità. Aggiungere la pulizia dei dati potrebbe effettivamente portare a miglioramenti. Per esempio, abbiamo osservato che semplicemente rimuovendo i tag HTML (cioè docs.map(item => item.html.replace(/<[^>]*>?/gm, '')) migliora significativamente la qualità delle raccomandazioni per il modello jina-reranker-v1, anche se l'effetto è meno pronunciato per il modello jina-colbert-v1. Questo suggerisce che il nostro modello ColBERT è stato addestrato per essere più tollerante al testo rumoroso rispetto al modello jina-reranker-v1.
• L'influenza di diverse costruzioni di query sulla qualità. Nell'implementazione sopra, abbiamo utilizzato direttamente il titolo e l'estratto dell'articolo corrente come query. È questo l'approccio ottimale per costruire la query? Aggiungere un prefisso come "What is the most related article to..." o"Ti darò 20$ se consigli il miglior articolo," simile ai prompt usati con i large language model, potrebbe essere utile? Questa solleva un'interessante questione, probabilmente legata alla distribuzione dei dati di training del modello, che prevediamo di esplorare ulteriormente.
• Sviluppando il punto precedente sulla costruzione delle query, sarebbe interessante investigare ulteriormente le capacità composizionali della query, come l'utilizzo della cronologia di navigazione recente dell'utente per raccomandazioni personalizzate. È particolarmente interessante considerare se il sistema potrebbe comprendere non solo esempi positivi nella query ma anche negativi, ad esempio operatori NOT_LIKE, "Non raccomandarmi articoli come questo" o "Voglio vederne di meno come questo". Approfondiremo questo aspetto nella prossima sezione.

tagStudio Empirico sulla Scrittura delle Query

Nella nostra esplorazione di diverse modalità di scrittura delle query con la Jina Reranker API, concentrandoci sui primi 10 risultati, abbiamo condotto una valutazione qualitativa attraverso l'etichettatura umana (cioè valutata da noi stessi), che ha senso poiché abbiamo piena conoscenza di tutti i contenuti pubblicati sul nostro sito web. Le strategie di scrittura delle query che abbiamo esaminato includevano:

• Utilizzo del Titolo dell'articolo, dell'Estratto e una combinazione di Titolo + Estratto.
• Adozione di istruzioni simili a "Prompt" come "altri simili a questo", "non come questo" e "qual è l'articolo più strettamente correlato?"

Per testare l'efficacia del reranker, abbiamo selezionato due articoli non banali come soggetti delle nostre query, mirando a identificare gli articoli più rilevanti tra il nostro vasto catalogo di oltre 200+ post—una sfida ispirata al concetto del "ago nel pagliaio" nei LLM. Di seguito, abbiamo evidenziato questi "aghi" in verde per chiarezza.

tagRiepilogo

Sulla base dei risultati dei test, abbiamo fatto alcune osservazioni e riassunti:

1. La combinazione di Titolo ed Estratto produce i migliori risultati di reranking, con l'Estratto che gioca un ruolo significativo nel migliorare la qualità del reranking.
2. L'incorporazione di istruzioni simili a "prompt" non porta ad alcun miglioramento.
3. Il modello reranker attualmente non elabora efficacemente i qualificatori positivi o negativi. Termini come "più simile a", "meno simile a" o "non come" non sono comprensibili dal reranker.

Le intuizioni dai punti 2 e 3 offrono interessanti direzioni per futuri miglioramenti del reranker. Riteniamo che abilitare il prompting al volo per modificare la logica di ordinamento potrebbe espandere significativamente le capacità del reranker, sbloccando nuove potenziali applicazioni come la curatela/raccomandazione personalizzata dei contenuti.