RAG #53
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Inefficienza Testo Libero
Lo scraping degli agenti dovrebbe essere salvato su sistema RAG così il team leader non deve fare lo spazzino.
Quindi intendi rimuovere il Team a favore di un RAG?
O aggiungere un altro Tool al Leader in modo che possa salvare in memoria dei dati?
O far passare i dati dai membri del team al Leader tramite degli output strutturati invece che testo libero?
Puoi elaborare un pò di più sul problema e se hai una proposta?
La mia idea è di usare il RAG come un sistema di "memoria" o "database di conoscenza" intermedio che viene popolato dagli agenti e consultato dal Team Leader.
Il flusso di lavoro diventerebbe questo:
Raccolta (Agenti): I 3 agenti (market, social, news) eseguono il loro scraping come fanno ora.
Indicizzazione (RAG): Invece di passare il testo grezzo al Leader, i loro risultati vengono "salvati" e indicizzati nel sistema RAG (ad esempio, spezzettati e trasformati in embeddings in un database vettoriale).
Recupero (Team Leader): Il Team Leader, per comporre la sua risposta, non legge più gli output grezzi. Invece, interroga il RAG con query specifiche (es. "Qual è il sentiment social sul nuovo prodotto?" o "Riassumi le news di mercato chiave di oggi").
Sintesi (Team Leader): Il RAG recupera solo i "chunk" di informazione più pertinenti e rilevanti dalle pagine o post scansionati. Il Team Leader riceve così un'informazione già filtrata e ad alta densità, e il suo lavoro si concentra sulla sintesi finale e non sulla pulizia preliminare.
Quindi, per rispondere alle tue opzioni: è una combinazione della 2 e della 3. Diamo un nuovo tool (il RAG) al Leader (opzione 2), che viene alimentato dagli agenti. Questo sistema gestisce la pertinenza molto meglio di un semplice "output strutturato" (opzione 3), perché permette di fare ricerche semantiche su grandi volumi di testo non strutturato. Quindi dopo varie interazioni con il chatbot abbiamo la possibilità di mantenere contesto sia con lo storico sia con i nuovi dati recuperati senza saturare la finestra di contesto.
In sintesi: automatizziamo il filtraggio e il recupero delle informazioni rilevanti (il lavoro da "spazzino") demandandolo al RAG, lasciando al Team Leader il compito di ragionamento e sintesi finale.
C'è un modello ollama specifico per questo lavoro: mxbai-embed-large. Pesa meno di un giga e lavora molto velocemente, lo provai insieme a Continue per lavorare sul progetto di tesi anche se fu un fallimento per via della poca intelligenza del modello locale che poi lo utilizzava.
Per me va bene, ma considera anche la possibilità di far fare il riassunto delle informazioni agli agenti del team direttamente.
Invece che fargli solo fare delle query e far passare i dati indietro, fare in modo che le elaborino un pochino per restituire un sentiment/ragionamento finale.
Questo solo perchè venerdì dovremmo consegnare e quindi non vorrei che sia troppo complesso da implementare.