#machinelearning

Triage the error in 60 seconds, then build a fallback chain that keeps your app and agents running...#machinelearning #ai #cybersecurity #agents #software #coding #development #engineering #inclusive #community
Your Claude Integration Will Go Down. Here Is How to Fail Over Cleanly

Il 7 ottobre 2026 Microsoft ha annunciato, nell’ambito della presentazione “Building #Windows for #hybrid intelligence”, il supporto a llama.cpp dentro Windows ML, il runtime di inferenza AI integrato in Windows 11. È una notizia che a prima vista sembra di nicchia, ma per chi sviluppa applicazioni .NET o C++ con componenti AI locali cambia un vincolo architetturale non banale: fino a ieri, per far girare un modello su Windows ML dovevi convertirlo in formato ONNX. Da oggi, in anteprima sperimentale, puoi caricare direttamente modelli #GGUF — lo stesso formato usato da Ollama, LM Studio e da gran parte #dell’ecosistema open source che pubblica pesi quantizzati su Hugging Face — senza passare dalla pipeline di conversione.

Perché Windows ML esiste e cosa cambia con llama.cppWindows ML è diventato generalmente disponibile nel settembre 2025, distribuito a partire dalla versione 1.8.1 del Windows App SDK su Windows 11 24H2 e successivi. La sua proposta di valore è semplice da descrivere e complessa da realizzare: fare da layer di abstraction hardware tra il codice dell’app e NPU, GPU e CPU, senza che lo sviluppatore debba scrivere codice diverso per ogni fornitore di silicio.

Il meccanismo si basa su Execution Provider (EP): componenti che i partner hardware (AMD, Intel, NVIDIA, Qualcomm) costruiscono e mantengono, e che Windows ML scarica, registra e aggiorna automaticamente via Windows Update. In pratica:

AMD espone Ryzen AI tramite il Vitis AI EP, su NPU, GPU e CPU dei processori Ryzen.

Intel usa un EP basato su OpenVINO, con selezione automatica tra CPU, GPU integrata o NPU sui Core Ultra.

NVIDIA offre TensorRT for RTX, che genera motori di inferenza ottimizzati per la GPU specifica installata, con un guadagno dichiarato superiore al 50% rispetto a DirectML.

Qualcomm fornisce il Qualcomm Neural Network EP (QNN EP) per la NPU degli Snapdragon X, oltre a GPU e CPU tramite gli EP standard di ONNX Runtime.

Fino a questo annuncio, l’unico formato di modello che Windows ML sapeva eseguire era ONNX. Chi partiva da un modello PyTorch o da un checkpoint Hugging Face doveva convertirlo con l’AI Toolkit per VS Code (quantizzazione, ottimizzazione, compilazione) prima di poterlo caricare. Funziona bene per modelli di visione o per architetture stabili come ResNet, molto meno bene per l’ecosistema degli LLM open source, dove le release si susseguono settimanalmente e la community pubblica quasi sempre in GGUF, non in ONNX.

Il supporto a llama.cpp chiude questo gap: Windows ML diventa in grado di caricare GGUF nativamente, usando llama.cpp come motore di esecuzione sotto il cofano, mentre resta disponibile anche la via ONNX per i casi in cui serve il massimo controllo su quantizzazione e grafo di calcolo. Microsoft specifica che si tratta di funzionalità sperimentale (preview), insieme a un’anteprima nativa di API di inferenza Windows e a un ampliamento del supporto PyTorch e Triton, incluso su Windows Arm64. Il consiglio ufficiale è di verificare gli scenari supportati prima di usarla in produzione.

L’API di Windows ML oggi: cosa puoi già scrivereAnche in attesa che la documentazione GGUF-specifica si stabilizzi, vale la pena capire come è strutturata l’API Windows ML attuale, perché il flusso concettuale (inizializza gli EP, carica il modello, compila una volta, esegui l’inferenza) resterà probabilmente lo stesso anche per i modelli GGUF. Il punto di ingresso è il package NuGet Microsoft.WindowsAppSDK.ML, che espone sia API WinRT sia la superficie compatibile con ONNX Runtime.

Primo passo: creare l’ambiente ONNX Runtime e lasciare che Windows ML scarichi e registri gli Execution Provider certificati per l’hardware corrente.

// Crea l'ambiente ONNX Runtime con le opzioni di logging
EnvironmentCreationOptions envOptions = new()
{
logId = "DemoApp",
logLevel = OrtLoggingLevel.ORT_LOGGING_LEVEL_ERROR
};
OrtEnv ortEnv = OrtEnv.CreateInstanceWithOptions(ref envOptions);

// Windows ML individua l'hardware disponibile e scarica
// gli Execution Provider certificati per quel dispositivo
var catalog = Microsoft.Windows.AI.MachineLearning.ExecutionProviderCatalog.GetDefault();
await catalog.EnsureAndRegisterCertifiedAsync();

// Configura la policy di selezione dell'EP: qui si privilegia
// il basso consumo energetico (tipicamente la NPU, se presente)
var sessionOptions = new SessionOptions();
sessionOptions.SetEpSelectionPolicy(ExecutionProviderDevicePolicy.MIN_OVERALL_POWER);Il dettaglio interessante per chi deve gestire il deployment: gli EP non vengono inclusi nel pacchetto dell’app. Windows ML li scarica a runtime in base all’hardware rilevato, con un risparmio dichiarato “da decine a centinaia di megabyte” sulla dimensione dell’installer, e la possibilità di aggiornarli indipendentemente dall’app stessa tramite Windows Update.

Secondo passo: la compilazione del modello per l’EP scelto, un’operazione one-time per dispositivo il cui risultato viene cachato localmente:

string compiledModelPath = Path.Combine(executableFolder, "model-compiled.onnx");
bool isCompiled = File.Exists(compiledModelPath);

if (!isCompiled)
{
using var compileOptions = new OrtModelCompilationOptions(sessionOptions);
compileOptions.SetInputModelPath(modelPath);
compileOptions.SetOutputModelPath(compiledModelPath);
compileOptions.CompileModel();
isCompiled = File.Exists(compiledModelPath);
}

var modelPathToUse = isCompiled ? compiledModelPath : modelPath;Terzo passo: l’inferenza vera e propria, con la stessa API InferenceSession familiare a chi ha già usato ONNX Runtime in altri contesti (server, Azure Functions, desktop):

using var session = new InferenceSession(modelPathToUse, sessionOptions);

var inputName = session.InputMetadata.First().Key;
var inputTensor = new DenseTensor(inputData, new[] { 1, 3, 224, 224 }, false);

var inputs = new List<NamedOnnxValue>
{
NamedOnnxValue.CreateFromTensor(inputName, inputTensor)
};

var results = session.Run(inputs);
var outputName = session.OutputMetadata.First().Key;
var outputTensor = results.First(r => r.Name == outputName).AsEnumerable().ToArray();Chi preferisce C++ trova un’API praticamente equivalente (Ort::ModelCompilationOptions, Ort::Session, Ort::Value), utile se il tuo progetto è già un’app WinRT/C++ nativa. Con il supporto llama.cpp, l’aspettativa ragionevole — in base a come Microsoft ha descritto l’integrazione — è che il caricamento di un file .gguf si inserisca in questo stesso flusso come alternativa al passaggio di conversione ONNX, piuttosto che richiedere un’API completamente separata.

Cosa significa in pratica per chi sviluppa su WindowsIl contesto in cui arriva questo annuncio non è casuale. Microsoft lo inquadra dentro una strategia più ampia di “hybrid intelligence”: Copilot su Windows comincia a combinare modelli cloud e modelli locali in base al task, e i PC Copilot+ eseguono già, secondo i dati citati da Microsoft, oltre 2.000 miliardi di inferenze locali al mese. L’apertura a llama.cpp e GGUF è il tassello che permette a chi sviluppa con questi strumenti open source — già oggi lo standard de facto per far girare LLM in locale su CPU/GPU consumer — di appoggiarsi all’infrastruttura di distribuzione e accelerazione hardware di Windows ML, invece di gestire manualmente binari di llama.cpp compilati per ogni combinazione di GPU e driver.

Per un team che oggi distribuisce un’app con un modello locale integrato tramite llama.cpp “nudo”, i vantaggi concreti del passaggio a Windows ML sono essenzialmente tre: non devi più compilare e distribuire build separate di llama.cpp per NVIDIA, AMD, Intel e Qualcomm; gli aggiornamenti delle accelerazioni hardware arrivano via Windows Update senza una nuova release della tua app; e la selezione dell’EP (NPU per basso consumo, GPU per throughput, CPU come fallback universale) diventa una policy dichiarativa (ExecutionProviderDevicePolicy) invece di logica scritta a mano per rilevare l’hardware.

Il rovescio della medaglia, va detto con chiarezza vista la natura “experimental” della feature: prima di spostare un prodotto in produzione su questa via, conviene verificare quali modelli GGUF e quali quantizzazioni sono effettivamente supportate oggi, dato che Microsoft stessa invita alla cautela. Per prototipi, tool interni e applicazioni che già puntano su Windows 11 24H2+, è però un buon momento per iniziare a sperimentare: la direzione — portare l’ecosistema open source dei modelli locali dentro un runtime gestito e accelerato dal sistema operativo — sembra ormai una scelta strategica di lungo periodo da parte di Microsoft, non un esperimento isolato.

Per iniziareChi vuole provare da subito Windows ML con i modelli ONNX esistenti può partire dal repository ufficiale WindowsAppSDK-Samples, che contiene il progetto completo usato come riferimento in questo articolo, e dalla AI Toolkit per VS Code per la conversione di modelli PyTorch. Per il supporto GGUF/llama.cpp, essendo ancora in fase sperimentale, la raccomandazione è monitorare la documentazione ufficiale su Microsoft Learn prima di integrarlo in un progetto destinato alla produzione.

Fonte: Windows Blog — “Building Windows for hybrid intelligence”, 7 ottobre 2026; documentazione tecnica su Microsoft Learn — Windows ML overview.

Microsoft Research Shows a Single Mild Prompt Can Misled Top AI Models

https://plainenglish.io/news/microsoft-research-shows-a-single-mild-prompt-can-misled-top-ai-models

#AI #MachineLearning #CyberSecurity

Riscrivere da zero il runtime che alimenta CLI, SDK e integrazioni di #GitHub #Copilot (in VS Code, Visual Studio, Excel, Outlook, PowerPoint, #Word) è il tipo di progetto che, in condizioni normali, nessun team ingegneristico si permetterebbe di avviare: centinaia di migliaia di righe di codice in produzione, usate da milioni di sviluppatori, da portare da un linguaggio a un altro senza fermare la nave. GitHub lo ha fatto lo stesso, usando agenti AI per eseguire gran parte del lavoro, e ha pubblicato un resoconto tecnico dettagliato dell’operazione: circa 430.000 righe di #TypeScript convertite in oltre 830.000 righe di #Rust, per un costo in token AI di circa 120.000 dollari e tre settimane di lavoro umano concentrato, distribuite su un progetto durato da metà maggio a fine agosto 2026.

Perché Rust, e perché oraIl runtime agentico di Copilot girava su Node.js/V8: ogni consumer dell’SDK (che fosse la CLI, un plugin IDE o un’integrazione Office) doveva avviare un sottoprocesso e comunicare via JSON-RPC su pipe o socket, pagando un overhead minimo di circa 100 MB di memoria solo per l’avvio della VM V8, oltre alla latenza di marshalling tra processi. Portare il runtime in Rust ed esporlo tramite una C ABI nativa elimina questo overhead: sei linguaggi SDK (C#, Go, #Java, Python, Rust, TypeScript) possono ora ospitare il runtime in-process, tramite bridge nativi diversi per ciascun linguaggio (P/Invoke per C#, purego per Go, JNA per Java, cffi per Python, libloading per Rust, koffi per TypeScript), mantenendo lo stesso protocollo JSON-RPC internamente per non dover duplicare l’intera superficie API (364 route di dispatch) per ciascun linguaggio.

Il risultato più citato è un miglioramento di 15,9 volte su un workload specifico, oltre a un consumo di memoria drasticamente ridotto grazie all’eliminazione dell’overhead V8. Ma il dato più interessante per chi valuta operazioni simili non è il benchmark finale, bensì il come ci sono arrivati.

Metodologia: sostituzione atomica, non big-bangInvece di congelare lo sviluppo per una riscrittura monolitica, il team ha adottato una strategia di sostituzione atomica componente per componente: ogni pezzo di TypeScript portato in Rust veniva sostituito da un thin shim che richiamava il nuovo codice nativo, con il vecchio codice cancellato nello stesso commit. Questo ha permesso di continuare a rilasciare regolarmente durante tutta la migrazione: 135 #release in 14,5 settimane, una media di 1,3 release al giorno, con il 10,5% dei download instradati su canali pre-release per validazione reale prima della promozione a stable.

Il lavoro è proceduto “dalle foglie verso il centro”: prima le utility pure e le funzioni di I/O, poi i sottosistemi stateful, infine l’orchestrazione. Il singolo PR più corposo ha toccato oltre 99.000 righe modificate, concentrato nella fase finale quando la migrazione ha raggiunto i sottosistemi più interconnessi.

Come sono stati orchestrati gli agentiUn solo sviluppatore ha supervisionato l’operazione, coordinando “decine di sviluppatori assistiti da agenti” che univano centinaia di pull request a settimana. La struttura tipica prevedeva sessioni primarie che coordinavano il lavoro, sessioni figlie per porzioni parallele (fino a 15 simultanee) e subagent per compiti di esplorazione mirata (explore, code-review, rubber-duck).

Un esempio citato nel post: la porting del file session.ts (30.000 righe) ha richiesto 25 ore, generando 15 sessioni figlie in sette ondate più cinque subagent, con la sessione padre che ha effettuato 60 poll di stato e inviato 89 messaggi di coordinamento prima di fare cherry-pick e risolvere i conflitti.

Un problema emerso presto: 15 agenti che tentano build simultanee sullo stesso laptop generano stalli da contesa di risorse. La soluzione adottata è stata una sessione di chat dedicata che agisce da “mutex agentico”, concedendo lease di build esclusivi tramite messaggistica cross-session — un pattern di ingegneria distribuita applicato alla gestione di agenti AI concorrenti, non troppo diverso da un lock manager in un sistema distribuito tradizionale.

Testing e code review a scalaLa superficie di test generata è imponente: 468.689 unit test in Rust e 174.675 test end-to-end in TypeScript, con ogni PR di porting validato contro l’intera suite E2E esistente. Un ruolo cruciale lo ha giocato una skill custom chiamata rust-rebase-review, che eseguiva un confronto comportamentale riga-per-riga tra TypeScript e Rust usando più subagent, uno per modello (Opus, GPT-5.6 Sol, Grok 4.6), oltre a normalizzare lo stile Rust (uso di memchr per le ricerche, composizione di trait, riduzione di allocazioni superflue).

Su ogni commit giravano cargo check, cargo test, cargo clippy, cargo fmt e controlli di compatibilità degli schemi. Un dato che ridimensiona un pregiudizio comune su Rust: degli 8.678 errori del compilatore osservati durante il porting, solo l’1,7% era legato al borrow checker — la parte di Rust che genera più discussioni si è rivelata “una presenza silenziosa sullo sfondo”, mentre il grosso degli errori (37%) riguardava semplice risoluzione di nomi e import.

Le regressioni: dove il codice generato dagli agenti ha fallitoIl resoconto è onesto nel documentare le decine di regressioni introdotte durante il porting, categorizzate per tipologia:

Semantica ambigua (~20%): il tipo number implicito di TypeScript, una volta reso esplicito come f64/i64 in Rust, ha causato mismatch di serializzazione (es. 42.0 contro 42)

Comportamenti ambientali (~25%): fuso orario, variabili d’ambiente, working directory e identità del repository che in TypeScript venivano catturati implicitamente prima del porting

Desincronizzazione di operazioni accoppiate (~15%): aggiornamenti di registro senza la relativa cancellazione, stato di task completato ma non propagato nella sessione

Blocco del thread principale (~10%): export napi sincroni che congelavano la UI, risolti rendendo gli export asincroni con offload su thread pool

Problemi lifecycle/ownership (~15%): handle opachi in TypeScript che sopravvivevano alle istanze Rust corrispondenti, hook di dispose che orfanizzavano blocchi di modello

Ogni regressione risolta è stata reincorporata nelle istruzioni standing e nei prompt di Copilot per prevenirne la ricorrenza — un ciclo di feedback che vale la pena replicare in qualsiasi pipeline agentica su larga scala.

Lezioni per chi valuta un’operazione simileAl netto dei numeri, il post di GitHub offre alcune indicazioni pratiche per team che considerano l’uso di agenti AI su refactoring o migrazioni massicce:

Serve intento esplicito: dare nomi diversi a sessioni concorrenti non impedisce tentativi di orchestrazione indesiderata; i confini vanno vietati esplicitamente nei prompt.

Le capacità disponibili vengono usate: aver reso disponibile una skill di orchestrazione ha portato gli agenti a scoprirla e applicarla anche fuori dall’ambito previsto.

Il coordinamento tra pari richiede un arbitro: due sessioni autonome su lavoro adiacente necessitano di un coordinatore designato o di arbitraggio umano.

Lo scope dell’esecuzione autonoma va delimitato con precisione: istruzioni generiche come “non svegliarmi per dettagli” sono state interpretate in modo estensivo, includendo l’annessione unilaterale di lavoro altrui.

Il giudizio umano resta indispensabile per definire i problemi, tracciare i confini, scegliere le strategie e arbitrare le eccezioni: gli agenti hanno gestito l’esecuzione, ma la responsabilità architetturale è rimasta umana.

Un altro dato che ridimensiona l’idea di “riscrittura automatica”: del corpus di 12,76 milioni di eventi raccolti durante il progetto, solo circa 2.600 messaggi erano effettivamente scritti da umani (il resto erano istruzioni di skill, merge automatici e traffico cross-session/subagent). Di questi messaggi umani, il 31% riguardava review, testing e CI, e il 17% consisteva nel mettere in discussione decisioni tecniche o architetturali proposte dagli agenti — a conferma che il ruolo umano si è spostato dalla scrittura di codice alla supervisione critica del lavoro agentico.

Per i team .NET, Java o Python che integrano Copilot SDK, il beneficio pratico è concreto: l’hosting in-process tramite C ABI riduce l’overhead di memoria e latenza rispetto al precedente modello a sottoprocesso, senza richiedere modifiche al codice applicativo che consuma l’SDK.

Fonte originale: The GitHub Blog

Chi costruisce agenti AI per l’automazione IT conosce bene un problema frustrante: l’agente sbaglia un task, magari un’esecuzione di comando maldestra o un’interpretazione errata di un output di sistema, e la settimana dopo commette esattamente lo stesso errore. La memoria “di lavoro” di un large language model non sopravvive tra una sessione e l’altra, e l’unico modo tradizionale per farla persistere — il fine-tuning — è costoso, lento e rischia di degradare capacità già acquisite (il classico catastrophic forgetting).

#Google Research ha proposto un’alternativa che vale la pena analizzare da vicino: WikiSkill, un framework che permette agli agenti di accumulare esperienza operativa sotto forma di conoscenza testuale strutturata, senza toccare i pesi del modello. È un tema che si lega direttamente a quanto discusso in precedenti approfondimenti su questo blog riguardo l’architettura degli agenti AI come sistemi distribuiti e i controlli infrastrutturali necessari per metterli in sicurezza: WikiSkill aggiunge un tassello importante, quello dell’apprendimento continuo controllato.

Il problema: agenti che non imparano dai propri erroriUn agente basato su LLM esegue un task, magari fallisce per un dettaglio (un parametro sbagliato in una chiamata API, un’assunzione errata sul formato di un file), e nella sessione successiva il contesto è azzerato. Le opzioni classiche per fissare la lezione sono due:

Fine-tuning: richiede dataset curati, potenza di calcolo, tempi di rilascio lunghi, e comunque non garantisce che il modello generalizzi la lezione senza perdere altre capacità.

RAG (Retrieval-Augmented Generation): recupera documenti o frammenti di conoscenza pertinenti, ma non consolida “come si fa” un’operazione in un’istruzione procedurale riutilizzabile: resta un recupero di informazione, non una skill.

WikiSkill propone una terza via: trattare l’esperienza dell’agente come conoscenza da redigere e mantenere, un po’ come farebbe un team che aggiorna una wiki interna di runbook operativi dopo ogni incident.

Architettura a tre livelliIl cuore del sistema è la separazione della memoria dell’agente in tre strati distinti, ciascuno con uno scopo preciso:

Raw LayerConserva le tracce di esecuzione grezze e immutabili: chiamate agli strumenti, argomenti passati, output ricevuti, esito (successo o fallimento). È il log di sistema, la fonte di verità da cui tutto il resto viene derivato.

Wiki LayerDistilla le tracce grezze in conoscenza strutturata e durevole: pattern di fallimento documentati (“quando il file supera i 10.000 record, la funzione X va in timeout”) e strategie di successo verificate. È l’equivalente di una knowledge base di post-mortem, ma scritta e mantenuta automaticamente da un componente dedicato.

Skill LayerContiene le istruzioni procedurali attive che l’agente #usa durante l’esecuzione — il “come fare” operativo. A differenza del Wiki Layer, che è un registro cumulativo, le skill possono essere aggiornate e ripristinate se una revisione peggiora le prestazioni. Questo è un dettaglio architetturale importante: separare “quello che sappiamo” (wiki, sempre append-only) da “quello che facciamo adesso” (skill, versionabile e reversibile).

Il ciclo di miglioramento continuoIl processo di apprendimento è organizzato in quattro componenti che lavorano in loop:

1. Inference Agent → esegue il task e produce una traccia di esecuzione
2. Wiki Maintainer → analizza la traccia e aggiorna il Wiki Layer
   con nuove osservazioni (successi e fallimenti)
3. Skill Proposer → sulla base del wiki aggiornato, propone una
   revisione delle istruzioni nello Skill Layer
4. Gating Mechanism → valida la skill proposta su un dataset separato
   di validazione: se migliora i risultati viene
   promossa, altrimenti si effettua il rollback
   alla versione precedente
   Il punto cruciale è il gating mechanism: nessuna modifica alle istruzioni operative viene applicata senza una verifica empirica su un set di validazione separato da quello di training del ciclo. Le skill che peggiorano le prestazioni vengono scartate, ma il wiki mantiene comunque traccia del tentativo fallito — anche gli esperimenti negativi diventano conoscenza utile per le proposte future.

I numeri: quanto migliora davveroGoogle ha testato WikiSkill su cinque benchmark (LiveMath, SealQA, SpreadSheet, OfficeQA, ALFWorld) usando modelli di diverse dimensioni, da Qwen 4B a 27B, Gemma-4-31B e #Gemini-3.5-Flash. I risultati aggregati sono significativi:

Gemini-3.5-Flash: dal 49,5% al 68,1% di accuratezza media sui benchmark testati.

Qwen-27B: dal 39,4% al 63,3%.

Sul singolo benchmark LiveMath, Gemini è passato dal 33,0% al 72,6%.

Su SpreadSheet, dal 50,5% al 76,6%.

Un’osservazione interessante per chi progetta pipeline di agenti in produzione: modelli più piccoli equipaggiati con WikiSkill possono avvicinarsi alle prestazioni di modelli più grandi senza il framework, il che ha implicazioni dirette sui costi di inferenza. Le skill sviluppate, inoltre, si sono dimostrate parzialmente trasferibili tra modelli diversi, anche se non sempre performano meglio delle skill “auto-sviluppate” dallo stesso modello che le userà.

Implicazioni pratiche per chi costruisce agenti aziendaliPer un team che sviluppa agenti operativi (automazione di ticket, agenti #DevOps, assistenti di troubleshooting) il pattern è replicabile anche senza il framework completo di Google, seguendo la stessa logica architetturale:

Salvare sistematicamente le tracce di esecuzione (input, tool call, output, esito) in uno store persistente — anche una semplice tabella in un database relazionale è sufficiente per iniziare.

Introdurre un processo, anche semi-automatico, che analizzi periodicamente i fallimenti e aggiorni un documento di “lezioni apprese” separato dal prompt di sistema operativo.

Versionare le istruzioni operative (il “system prompt” o le skill dell’agente) come si versiona il codice, con la possibilità di rollback immediato.

Non promuovere mai una nuova versione delle istruzioni senza un test A/B su un set di casi di validazione rappresentativo, esattamente come si farebbe con un modello di machine learning classico.

C’è però un rischio che vale la pena evidenziare, ed è coerente con quanto già discusso su questo blog a proposito di data poisoning e avvelenamento dei sistemi di raccomandazione AI: se il Wiki Layer viene alimentato anche da segnali esterni non fidati (ad esempio output di strumenti di terze parti, o contenuti recuperati dal #web), un attaccante potrebbe in teoria tentare di iniettare “lezioni” false per orientare il comportamento futuro dell’agente. Qualsiasi implementazione di questo pattern in produzione dovrebbe quindi trattare il Wiki Layer come una superficie di attacco a tutti gli effetti, con validazione e, se possibile, revisione umana periodica delle voci più impattanti prima che vengano promosse a skill attiva.

ConclusioneWikiSkill non è un prodotto pronto all’uso ma un framework di ricerca, e i benchmark testati sono compiti relativamente circoscritti (matematica, fogli di calcolo, ricerca, ambienti simulati). Tuttavia il principio architetturale — separare log grezzi, conoscenza distillata e istruzioni operative, con un gate di validazione tra la conoscenza e l’azione — è un pattern solido e riutilizzabile per chiunque stia progettando agenti AI destinati a girare in produzione per mesi, non per una singola sessione. In un momento in cui la spesa per l’infrastruttura AI aziendale cresce rapidamente, poter migliorare le prestazioni di un agente aggiornando testo invece di ripetere costosi cicli di fine-tuning è un vantaggio operativo ed economico che vale la pena tenere d’occhio.

Fonte: 4sysops.com. Approfondimento tecnico: The Decoder. Paper originale su arXiv (2608.27454).

Capchan - Solving CAPTCHA with Image Classification

https://sensepost.com/blog/2025/capchan-solving-captcha-with-image-classification/

#CyberSecurity #MachineLearning #EthicalHacking