Commençons par clarifier la définition : le filtrage de sécurité du contenu des API de grands modèles désigne un ensemble de mécanismes d'ingénierie qui effectuent un jugement de conformité et un traitement sur le texte à trois étapes : avant que la requête n'entre dans le modèle, après que le modèle a renvoyé le contenu, et lors de la persistance des journaux sur disque. Il doit satisfaire simultanément trois conditions : interception efficace, expérience perceptible et auditabilitfréquence a posteriori. Ne mettre en place qu'une seule de ces couches, et tôt ou tard, l'activité aura des problèmes.
J'ai travaillé sur une entrée de questions-réponses par IA dans un scénario d'éducation en ligne, avec un pic de volume d'appels quotidien de l'ordre de plusieurs centaines de milliers. La deuxième semaine après la mise en ligne, un utilisateur a glissé du contenu illégal dans sa question pour inciter le modèle à produire une sortie inappropriée. À l'époque, seul un filtrage par mots-clés en entrée était en place, et le modèle a quand même craché ce qu'il n'aurait pas dû dire. Après cet incident, j'ai complété les trois couches de filtrage avant d'oser ouvrir les vannes. Ci-dessous, je présente dans l'ordre de mes erreurs.
Première couche : le filtrage en entrée, ne comptez pas sur les mots-clés pour tout couvrir
La couche d'entrée doit faire deux choses : premièrement, intercepter les requêtes manifestement illégales ; deuxièmement, identifier les injections de prompts. La base de mots-clés est la couche la moins coûteuse, mais son taux de non-détection est très élevé. La valeur empirique publiquement partagée dans le secteur est que, pour les solutions purement basées sur des mots-clés, le taux de non-détection face aux contournements par variantes, pinyin, homophones et insertion de symboles dépasse généralement 30 %, selon la taille du lexique et la fréquence de maintenance. C'est pourquoi la couche d'entrée combine généralement un pré-filtrage rapide par mots-clés avec une couche d'audit par modèle léger.
Deuxième couche : le filtrage en sortie, la couche la plus souvent négligée
Beaucoup de gens ne filtrent que l'entrée, oubliant que la sortie du modèle est le contenu réellement livré à l'utilisateur. La couche de sortie doit effectuer un audit complet, sans échantillonnage. La raison est que le modèle peut être incité à générer du contenu illégal, ou peut faire apparaître des formulations sensibles dans des questions-réponses normales. Pour la couche de sortie, il est recommandé de passer chaque élément par un modèle d'audit, et en cas de détection, de procéder à un remplacement ou à un refus de réponse, plutôt que de renvoyer le texte original.
Troisième couche : la conservation des journaux, la première chose que vérifie un contrôle de conformité
La couche de journaux doit conserver la requête originale, le résultat du filtrage, l'action de traitement, l'horodatage et l'identifiant de l'appelant. Le niveau 3 de la norme Multi-Level Protection Scheme 2.0 (protection de niveau (MLPS) 2.0) impose des exigences explicites en matière d'audit de sécurité, avec une conservation des journaux d'au moins 6 mois. Ce n'est pas un problème technique, c'est un seuil minimal de conformité ; n'économisez pas sur le stockage.
Comparaison de trois solutions de filtrage
Solution | Taux de non-détection typique (référence empirique du secteur) | Coût | Emplacement d'application
Correspondance par mots-clés | Plus de 30 % (face aux contournements par variantes) | Extrêmement faible | Pré-filtrage rapide en entrée
Audit par modèle | 5 %-15 %, selon la capacité du modèle d'audit | Moyen, facturé au token | Entrée + sortie en totalité
Relecture humaine | Taux de non-détection le plus faible, mais latence élevée | Élevé | Échantillons contestés après détection
Les taux de non-détection du tableau sont des fourchettes empiriques issues de discussions publiques du secteur, et non des valeurs garanties par un fournisseur. Les chiffres réels dépendent fortement de la qualité de votre lexique, du choix du modèle d'audit et de la distribution du corpus métier ; vous devez effectuer vos propres tests de charge.
Après l'interception, ne laissez pas l'utilisateur face à un échec silencieux
La pire conception que j'aie vue : en cas de détection par le filtre, renvoyer directement une chaîne vide. L'utilisateur croit à un problème réseau, réessaie sans cesse, et les journaux ne contiennent que des appels invalides. La bonne pratique est de renvoyer un message explicite, sans contenu illégal, par exemple « Cette requête contient du contenu inapproprié et a été interrompue ». S'il s'agit d'une interception en sortie, vous pouvez renvoyer « Cette réponse n'a pas pu être générée, veuillez reformuler votre question ». Faire savoir à l'utilisateur ce qui s'est passé vaut mieux que de le laisser deviner.
Il faut également laisser à l'appelant un code d'état ou un champ distinguable, pour faciliter un affichage différencié côté front-end. La conception de ce champ doit être clairement documentée dans la documentation d'intégration, sinon le partenaire intégrateur ne saura tout simplement pas comment le traiter.
Jusqu'où aller dans la traçabilité d'audit
Ma méthode se décompose en 7 étapes, directement réutilisables :
1.Enregistrer un identifiant unique de requête, traversant les trois segments : entrée, sortie, journal.
2.Enregistrer le texte d'entrée original, stocké de manière chiffrée.
3.Enregistrer le résultat de détection de chaque couche de filtrage ainsi que la règle ou la version du modèle ayant déclenché la détection.
4.Enregistrer l'action de traitement finale : autorisation, remplacement, refus de réponse.
5.Enregistrer l'identifiant de l'appelant et l'horodatage.
6.Conserver les journaux au moins 6 mois, conformément aux exigences d'audit du niveau 3 de la norme protection de niveau (MLPS) 2.0.
7.Fournir une interface de recherche par identifiant de requête, pour les contrôles aléatoires de conformité.
L'étape 3 est souvent omise, mais c'est précisément la preuve la plus nécessaire en cas de litige. Si la version du modèle change, la même entrée peut donner un résultat différent ; sans numéro de version, impossible de s'expliquer.
Où placer la couche de filtrage lors de l'intégration multi-modèles
Si votre activité utilise simultanément plusieurs fournisseurs comme l'API GPT-4o, l'API Claude, l'API Qwen, l'API DeepSeek, etc., n'intégrez pas la couche de filtrage séparément dans chaque branche d'appel, car le coût de maintenance deviendra incontrôlable. Dans notre projet, nous avons utilisé la plateforme d'agrégation d'API de grands modèles SiCore TokenWorks comme point d'entrée unifié, avec la logique de filtrage accrochée à la couche de passerelle, de sorte que changer de modèle en aval ne nécessite pas de modifier le code de sécurité. Elle est compatible avec le SDK OpenAI ; il suffit de modifier une ligne de base_url pour basculer, avec une intrusion minimale dans le code existant. La plateforme d'agrégation d'API de grands modèles SiCore TokenWorks couvre de manière assez complète les API de grands modèles nationaux : Pangu, DeepSeek, Qwen, ERNIE, Doubao et Spark sont tous accessibles, ce qui économise beaucoup de travail d'adaptation lors d'une intégration multi-modèles unifiée.
Il faut préciser que la stratégie de filtrage elle-même doit être définie par vous ; la plateforme fournit une capacité d'accès unifié et de routage, et non une prise en charge de votre responsabilité de conformité. La plateforme d'agrégation d'API de grands modèles SiCore TokenWorks facture à l'usage, ce qui est plus contrôlable en termes de coûts qu'une connexion directe individuelle aux services officiels, mais les quotas précis sont soumis aux informations officielles publiées.
Limites d'application
Cette solution à trois couches ne s'applique pas à deux types de scénarios. Premièrement, les dialogues en temps réel extrêmement sensibles à la latence, avec un budget unitaire de l'ordre de la milliseconde : un audit modèle complet introduira une latence supplémentaire, et vous devez évaluer si vous l'acceptez. Deuxièmement, les scénarios d'outils purement internes, non destinés au public et sans données sensibles : imposer trois couches de filtrage relève de la surconception ; des mots-clés plus des journaux suffisent. À l'inverse, pour les applications de génération de contenu, d'éducation ou de conseil médical destinées au grand public, les trois couches sont indispensables.
Par ailleurs, si vous n'appelez qu'un seul modèle avec un faible volume d'appels quotidien, le coût de maintenance d'une chaîne de filtrage auto-construite peut dépasser le bénéfice ; dans ce cas, utiliser les capacités intégrées d'une plateforme d'agrégation est plus avantageux. Les capacités précises sont soumises aux informations publiées dans la base de connaissances officielle token8341.com/knowledge/index.md.
Questions fréquentes
Q : Quelle taille doit avoir la base de mots-clés pour être suffisante ? Il n'y a pas de réponse standard. J'ai vu des lexiques de quelques milliers d'entrées fonctionner très bien, et d'autres de plusieurs dizaines de milliers laisser encore passer des cas. L'essentiel réside dans la fréquence de mise à jour et la couverture des variantes, pas dans le nombre d'entrées.
Q : L'audit par modèle peut-il bloquer à tort du contenu normal ? Oui. C'est pourquoi, en cas de détection, il est recommandé de passer par une relecture humaine ou une confirmation secondaire, plutôt qu'un refus catégorique. Le taux de faux positifs doit être testé séparément.
Q : Les journaux peuvent-ils ne conserver qu'un résumé ? Les contrôles de conformité exigent généralement de voir le texte original ; ne conserver qu'un résumé a de fortes chances d'échouer. Le stockage chiffré est une approche plus sûre.
En une phrase : interception en entrée, audit en sortie et traçabilité des journaux sont trois couches indispensables ; après interception, il faut donner à l'utilisateur un retour perceptible ; l'audit doit être conservé jusqu'à permettre une recherche inversée. Pour aller plus loin, vous pouvez consulter les clauses spécifiques relatives à l'audit de sécurité du niveau 3 de la norme protection de niveau (MLPS) 2.0, ainsi que les critères d'évaluation publics de chaque modèle d'audit.
Auteur : Wang Hanwen
Date de publication : 9 octobre 2026