Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Le migliori pratiche per evitare attacchi di iniezione tempestiva
I seguenti guardrail e le migliori pratiche sono stati testati su un'applicazione RAG basata su Anthropic Claude come modello dimostrativo. I suggerimenti sono ampiamente applicabili alla famiglia di modelli Claude, ma sono anche trasferibili ad altri LLM non Claude, in attesa di modifiche specifiche del modello (come la rimozione dei tag XML e l'utilizzo di diversi tag di attribuzione di dialogo).
<thinking><answer>Uso e tag
Un'utile aggiunta ai modelli RAG di base sono <thinking> i <answer> tag. <thinking>i tag consentono al modello di mostrare il proprio lavoro e di presentare eventuali estratti pertinenti. <answer>i tag contengono la risposta da restituire all'utente. Empiricamente, l'utilizzo di questi due tag consente di migliorare la precisione quando il modello risponde a domande complesse e articolate che richiedono l'unione di più fonti di informazioni.
Usa i guardrail
La protezione di un'applicazione basata su LLM richiede barriere specifiche che riconoscano e aiutino a difendersi dagli attacchi comuni descritti in precedenza. Quando abbiamo progettato le barriere di sicurezza di questa guida, il nostro approccio era quello di ottenere il massimo vantaggio con il minor numero di token introdotti nel modello. Poiché la maggior parte dei fornitori di modelli addebita in base al token di input, i guardrail con meno token sono efficienti in termini di costi. Inoltre, è stato dimostrato che modelli troppo ingegnerizzati riducono la precisione.
Avvolgi le istruzioni in un unico paio di etichette di sequenza salate
Alcuni LLM seguono una struttura a modello in cui le informazioni sono racchiuse in tag XML<tagname-abcde12345> Un'istruzione aggiuntiva ordina al LLM di prendere in considerazione solo le istruzioni che si trovano all'interno di questi tag.
Un problema di questo approccio è che se il modello utilizza i tag nella sua risposta, in modo previsto o imprevisto, anche la sequenza salata viene aggiunta al tag restituito. Ora che l'utente conosce questa sequenza specifica della sessione, può eseguire lo spoofing dei tag, possibilmente con maggiore efficacia grazie all'istruzione che ordina all'LLM di prendere in considerazione le istruzioni con tag salt. Per aggirare questo rischio, racchiudiamo tutte le istruzioni in un'unica sezione con tag del modello e utilizziamo un tag che consiste solo nella sequenza salata (ad esempio,). <abcde12345> Possiamo quindi indicare al modello di prendere in considerazione solo le istruzioni in questa sessione con tag. Abbiamo scoperto che questo approccio ha impedito al modello di rivelare la sua sequenza predefinita e ha contribuito a difendersi dal tag spoofing e da altri attacchi che introducono o tentano di potenziare le istruzioni del modello.
Insegna al LLM a rilevare gli attacchi fornendo istruzioni specifiche
Includiamo anche una serie di istruzioni che spiegano i modelli di attacco più comuni, per insegnare all'LLM come rilevare gli attacchi. Le istruzioni si concentrano sulla richiesta di input dell'utente. Indicano all'LLM di identificare la presenza di schemi di attacco chiave e restituiscono «Prompt Attack Detected» se rileva uno schema. La presenza di queste istruzioni ci consente di fornire all'LLM una scorciatoia per affrontare gli attacchi più comuni. Questa scorciatoia è importante quando il modello utilizza <thinking> e <answer> contrassegna, poiché l'LLM di solito analizza le istruzioni dannose in modo ripetitivo e con dettagli eccessivi, il che alla fine può portare alla conformità (come dimostrato nei confronti nella sezione successiva).
