RAG in produzione su larga scala: lezioni apprese da oltre 10.000 annunci al giorno
Ho costruito una pipeline RAG per un job board. Funzionava in staging, ma ha faticato sotto il carico reale. Elaborare migliaia di annunci ogni giorno richiede molto più di un buon vector store. Devi capire dove il sistema si rompe.
Ecco le mie lezioni su chunking, embeddings, costi e osservabilità.
- Non andare a tentoni con la strategia di chunking
La maggior parte dei tutorial tratta il chunking come una semplice impostazione. In produzione, la tua strategia determina l'accuratezza e il costo.
Ho testato tre metodi per gli annunci di lavoro:
- Chunk a dimensione fissa: hanno fallito. Dividevano sezioni come "requisiti" e "benefit" in punti casuali. Questo crea un retrieval rumoroso.
- Semantic chunking: era migliore ma inconsistente. Alcuni chunk erano troppo lunghi e altri troppo brevi.
- Recursive character splitting con overlap: è stato il metodo migliore. Ho diviso su nuove righe e frasi. Ho utilizzato una dimensione di 400 token con un overlap di 50 token. Questo assicura che le frasi che si estendono su due chunk rimangano connesse.
Pro tip: Normalizza i tuoi dati prima del chunking. Diverse fonti come Greenhouse o Lever restituiscono formati differenti. Pulisci prima il testo, in modo che il tuo chunker veda una struttura coerente.
- Embeddings: Costo vs. Accuratezza
Ho testato Llama 3.1 tramite Ollama rispetto a OpenAI text-embedding-3-small. Il modello locale era gratuito ma faticava con termini specifici del settore come "equity compensation". Produceva risultati rumorosi. OpenAI costava di più ma forniva corrispondenze accurate. Ho scelto OpenAI perché un retrieval scadente costa di più in termini di chiamate LLM in seguito.
Per risparmiare tempo, raggruppo le richieste in batch. Invio fino a 100 chunk in una singola chiamata. Questo riduce la latenza e mantiene la pipeline veloce.
- Il compromesso del Vector Store
Ho usato Pinecone per la prototipazione perché è veloce da configurare. Tuttavia, su larga scala, i costi sono diventati troppo elevati.
Sono passato a pgvector all'interno di PostgreSQL.
- È stato più impegnativo da configurare.
- Ha permesso di risparmiare ingenti somme di denaro.
- Ha fornito coerenza transazionale. Poiché gli embeddings risiedono nello stesso database dei dati degli annunci, hai un'unica fonte di verità. Non è necessario sincronizzare due sistemi diversi.
- Controllare i costi degli LLM
Valutare ogni annuncio con GPT-4o è costoso. Ho utilizzato tre tattiche per ridurre i costi:
- OpenAI Batch API: elaboro i lavori di valutazione durante la notte. Questo offre un grande sconto.
- Caching: metto in cache i risultati per i profili dei candidati ricorrenti.
- Model tiering: utilizzo GPT-4o-mini per ruoli comuni come "Sales Representative". Uso GPT-4o solo per ruoli di nicchia dove la precisione è vitale.
- Costruisci prima l'osservabilità
Una volta la mia pipeline è fallita silenziosamente. Dati malformati hanno causato chunk vuoti, che il sistema ha saltato senza restituire errori.
Ho risolto il problema aggiungendo un logging strutturato con un correlation ID. Ciò mi ha permesso di tracciare un singolo annuncio dall'ingestione alla valutazione. Ho potuto finalmente vedere quali fonti dati stavano causando i fallimenti.
La lezione più importante: la maggior parte dei problemi deriva da dati disordinati, non dall'IA. Sistema prima l'impianto dei tuoi dati.
Optional learning community: https://t.me/GyaanSetuAi