Un tutorial di Fivetran del marzo 2024 mostra come costruire un chatbot di helpdesk sopra i dati Zendesk ospitati in un data lake S3. Lo stack: Python, GPT-4 come foundation model, ChromaDB come vector database, LangChain a fare da collante, Athena come query engine e Streamlit per il front end. Il codice completo è su GitHub nel repository fivetran/zendesk_qnabot.
La parte che conta è il SQL
Il pezzo più istruttivo non è il RAG, che è ormai standard, ma la trasformazione a monte. I dati Zendesk hanno una relazione uno-a-molti tra ticket e commenti, che va appiattita in uno-a-uno prima di vettorizzare. Il file query.sql parte da una CTE che usa ROW_NUMBER() OVER(PARTITION BY tc.ticket_id ORDER BY tc.created) per ordinare e numerare i commenti dal più vecchio al più recente, concatenando ciascuno con i campi di contesto — nome, email e ruolo dell’utente — così da poter poi interrogare il bot su partecipanti specifici.
La query successiva usa LISTAGG(...) WITHIN GROUP (ORDER BY cr.comment_created) per ricomporre i blocchi di testo in un unico record per ticket, con ID, subject, data di creazione, status e priority in testa. Come nota il post, il problema uno-a-molti sui commenti è ricorrente in tutti i modelli di dati chat con grossi blocchi testuali: la soluzione vale ben oltre Zendesk.
Il resto della pipeline
Il progetto si compone di quattro file: bot.py, load_vec_db.py, query.sql e requirements.txt. Prerequisiti: Python 3.9 o superiore, virtualenv, e le librerie boto3, chromadb, langchain, langchain-community, langchain-openai, openai, streamlit e tiktoken.
load_vec_db.py usa AthenaLoader di LangChain per estrarre i documenti dal data lake, li vettorizza con OpenAIEmbeddings e li persiste su Chroma. bot.py dichiara il prompt template, istanzia ChatOpenAI con gpt-4-0125-preview e compone la catena RAG con il retriever di Chroma, chiudendo su un form Streamlit.
I limiti, dichiarati
Il post è onesto sui punti deboli. L’ETL verso il vector database non è incrementale e può richiedere tempo: va rilanciato a mano quando i dati sottostanti sono cambiati abbastanza. E l’autore elenca le direzioni di miglioramento: astrarre il processo SQL in una libreria o in un dbt model, filtrare e ottimizzare il retrieval per topic o contesto, valutare knowledge graph che codifichino fatti espliciti invece delle sole associazioni statistiche tra parole.
Come esercizio è un buon punto di partenza, a patto di trattare la parte di refresh come il vero problema di produzione — perché lo è.
In sintesi
- Il valore del tutorial sta nella trasformazione SQL che appiattisce la relazione ticket-commenti prima della vettorizzazione.
- Lo stack è LangChain con Athena come loader, ChromaDB come vector store, GPT-4 come modello e Streamlit come front end.
- L’ETL verso il vector database non è incrementale: il refresh va gestito a mano ed è il punto debole in produzione.
Fonte: Building a chatbot with Fivetran and LangChain — https://www.fivetran.com/blog/building-a-chatbot-with-fivetran-and-langchain
Hai qualcosa da aggiungere? Unisciti alla discussione.