Filtrare grossolanamente, validare in dettaglio: il consiglio emerge da solo
Combinando un filtro grossolano (PIM con attributi tipizzati) e una validazione chirurgica (Knowledge Tool con LLM-judge), la shortlist diventa comparativa senza che tu lo chieda. Il consiglio emerge dalla composizione.
Sto costruendo un sistema di configurazione prodotto cross-brand per la PMI dove lavoro: l'utente descrive un caso d'uso in prosa libera ("guida cassetto da 500 millimetri, portata 40 chili, peso anta 60 chili") e il sistema deve proporre i prodotti compatibili dei vari fornitori, con motivazione tecnica.
L'architettura e' a due livelli. Un PIM cross-brand con attributi tipizzati per categoria (profondita', portata, altezza, attacco): filtra in modo deterministico ma grossolano, ottimizzato per recall alto. Un Knowledge Tool per ogni fornitore, ognuno con il suo wiki di regole tecniche curato dall'esperto interno e validate via LLM-judge: ottimizzato per precisione alta. Il supervisore orchestra: filtro grossolano in PIM, poi validazione chirurgica per ogni candidato, poi sintesi in tre stati (consigliato | compatibile | sconsigliato).
Il pattern in se' e' canonico nel mondo CPQ industriale (Constructor.com lo cita, Akeneo PIM lo formalizza). Non l'ho inventato io. Quello che ho osservato testandolo end-to-end e' una proprieta' emergente che non avevo pianificato.
Test reale: query "guida cassetto profondita' 500 mm, portata 40 kg, peso anta 60 kg". Il filtro PIM ha tornato due candidati: una guida da 40 kg di portata e una da 70 kg, entrambe da 500 mm di profondita'. La validazione del Knowledge Tool ha valutato il contesto "peso anta 60 kg" sui due candidati separatamente: la guida da 40 kg e' stata bloccata (peso eccede portata), la guida da 70 kg approvata. La shortlist finale propone entrambe con motivazioni opposte: "ti propongo la 70 kg, mentre la 40 kg non regge il tuo peso anta".
Questo output comparativo e' il valore consulenziale del CPQ industriale, ed emerge dalla composizione delle due fonti. Non l'ho chiesto. Non c'e' un agente LLM che decide "fammi un confronto"; il confronto nasce perche' il filtro restituisce candidati alternativi (recall) e la validazione li discrimina sul contesto specifico (precisione).
La conseguenza pratica e' che lo strato di sintesi del supervisore puo' essere una pura funzione deterministica di una decina di righe: aggrega le validazioni per brand, applica regole conservative ("in conflitto vince chi blocca"), ritorna i tre stati. Niente LLM ricorsivo, niente relax automatico del filtro, niente prompt elaborati. La parte intelligente e' nei due strati a monte; lo strato di sintesi e' un commodity.
Caveat onesto: ho scoperto questa proprieta' anche grazie a un bug del mio parser deterministico (un'espressione regolare che mancava di catturare un attributo, allargando di fatto il filtro). Se il parser fosse stato perfetto, il filtro avrebbe ritornato un solo candidato e la shortlist comparativa non sarebbe emersa per quella query specifica. Pero' la stessa query riformulata diversamente, oppure altre query in cui un attributo non e' stato menzionato, producono la stessa proprieta'. Il bug ha solo reso visibile prima cio' che esiste comunque.
Metto in nota: per chi costruisce sistemi simili, vale la pena testare con query parziali o ambigue prima di rifinire il parser. Le proprieta' emergenti del pattern si vedono meglio quando gli stadi a monte sono "gentilmente imprecisi".
Riferimenti: il case study sull'architettura wiki e quello sul knowledge base AI-maintained raccontano il livello sotto, dove vivono le regole tecniche.