Tous les produits
Search
Centre de documentation

Vector Retrieval Service for Milvus:Mettre en place un garde-fou de sécurité du contenu pour la réponse aux questions par IA avec Data inspection dans Alibaba Cloud Milvus

Dernière mise à jour :Aug 13, 2026

Ajoutez un garde-fou de sécurité du contenu à une application de réponse aux questions par IA en activant un simple commutateur data_inspection dans une AI Function Alibaba Cloud Milvus existante. Ce tutoriel explique comment ce commutateur inspecte les entrées utilisateur avant l'appel au modèle et examine les sorties du modèle avant le renvoi du résultat. Il détaille également la manière dont le client synthétise les résultats d'interception en trois dispositions mutuellement exclusives : policy_blocked, manual_review et operational_error.

Présentation de la solution

Dès qu'un grand modèle traite du trafic externe, la sécurité du contenu cesse d'être un simple atout pour devenir une condition sine qua non de mise en production. Lorsque des utilisateurs réels soumettent des prompts d'un côté et que le modèle génère du texte de l'autre, deux expositions aux risques apparaissent simultanément :

  • Côté entrée (utilisateur vers modèle) — Les utilisateurs peuvent soumettre du contenu non conforme ou utiliser des prompts de contournement (jailbreak) pour pousser le modèle au-delà de ses limites de sécurité. Le contenu généré par les utilisateurs, tel que les publications, les commentaires et les pseudonymes, doit également franchir une barrière de sécurité avant son stockage.

  • Côté sortie (modèle vers utilisateur) — Même lorsque l'entrée semble normale, le modèle peut générer du contenu non conforme, comme des textes marketing contenant des promesses exagérées ou des déclarations biaisées. Ce phénomène est particulièrement visible dans la rédaction publicitaire et la génération de scripts, où le modèle dispose d'une marge d'improvisation. Une barrière est nécessaire aux deux extrémités, ce qui apporte une valeur commerciale directe. La sécurité du contenu constitue une exigence stricte pour l'enregistrement et le lancement d'applications basées sur de grands modèles. Une fois que les machines bloquent la grande majorité des contenus clairement non conformes, les modérateurs ne traitent plus qu'un petit nombre d'échantillons ambigus. L'équipe de modération passe ainsi d'une revue systématique à l'examen des seuls cas complexes. Une simple capture d'écran d'un contournement réussi ou une déclaration inappropriée peut se transformer en incident public ; le garde-fou permet de stopper ce risque avant que le contenu ne quitte le système.

L'assemblage de cette capacité selon une approche traditionnelle se heurte à plusieurs difficultés :

  • Les inspections aux deux extrémités s'effectuent à des moments différents — L'inspection des entrées doit se terminer avant l'appel au modèle, tandis que celle des sorties doit s'achever avant le renvoi du résultat. Un seul appel métier englobe ces deux points autour de l'appel au modèle.

  • Un service de sécurité du contenu supplémentaire doit être intégré et chaîné manuellement — Dans une implémentation classique, le code métier appelle une API de sécurité du contenu pour inspecter l'entrée, puis invoque le grand modèle, et rappelle enfin l'API d'inspection pour la sortie. Cela implique trois appels distants, trois politiques de délai d'attente et de nouvelle tentative, ainsi que trois chemins d'authentification.

  • L'analyse programmatique des résultats d'interception est complexe — Lorsqu'une politique de sécurité est déclenchée, le serveur peut renvoyer une erreur HTTP, un code métier non nul, ou encore un refus explicite sous forme de texte au sein d'une réponse HTTP 200. Vérifier uniquement le code de statut HTTP fait manquer les refus inclus dans les réponses 200, tandis que la recherche exclusive de mots-clés provoque des faux positifs sur des textes métier normaux contenant fortuitement des termes comme « risque » ou « rejet ».

  • Le compromis entre faux positifs et faux négatifs — Une barrière trop stricte perturbe l'activité normale, tandis qu'une barrière trop permissive accroît le risque de conformité. Un garde-fou ne saurait se limiter aux états « autorisé » et « bloqué » ; il nécessite également un état intermédiaire dirigeant les échantillons ambigus vers une revue manuelle.

  • Conformité des journaux — Le dépannage exige des journaux, mais dès que du texte brut à haut risque et des informations personnelles sensibles y sont consignés en clair, le système de journalisation devient lui-même une nouvelle surface de fuite. L'approche retenue dans Alibaba Cloud Milvus consiste à ajouter un commutateur data_inspection aux params d'une AI Function existante, telle que la tâche de génération de texte ai_text_generate. Ce commutateur n'accepte que trois valeurs :

Valeur Moment de l'inspection Scénario typique Description
input Avant l'appel au modèle Service client intelligent et assistants IA recevant des prompts utilisateurs ; contenu UGC avant stockage Bloque les prompts de contournement et les entrées non conformes. Son déclenchement empêche l'appel au modèle, ce qui économise des ressources de calcul et renforce la sécurité.
output Avant le renvoi du résultat Publication de copies marketing et promotionnelles, génération de scripts Convient aux scénarios où l'entrée est fiable et où seule la conformité de la sortie du modèle préoccupe.
both Une fois à chaque extrémité Dialogue ouvert à haut risque, réponse libre aux questions face au public Offre la barrière la plus robuste lorsque aucune des deux extrémités n'est fiable, mais s'avère aussi la plus coûteuse.

Le garde-fou et l'appel au modèle s'exécutent en un seul passage au sein de Milvus, de sorte que les données ne quittent jamais l'instance Milvus. L'administrateur configure les identifiants de manière centralisée côté Provider ; ils ne sont jamais inscrits dans le corps d'une requête. Ainsi, la partie métier n'a plus besoin de construire ni de chaîner un service externe de sécurité du contenu.

data_inspection ajoute une barrière à un appel existant sans remplacer les paramètres obligatoires de la tâche elle-même. Par exemple, la génération de texte nécessite toujours texts ; son omission renvoie l'erreur texts is required for task [ai_text_generate].

Prérequis

  • Une instance Milvus 2,6 est créée. AI Function repose sur le noyau 2,6 et ne requiert aucune liaison séparée à un service de modèle après la création.

  • Pour accéder à l'instance via Internet, Public Access est activé dans l'onglet Security Configuration de la page de détails de l'instance, et l'adresse IP sortante du client figure dans la liste d'autorisation d'accès public.

  • Un modèle de texte cible est configuré côté Provider, avec la capacité Data inspection (DATA_INSPECTION) disponible. Le commutateur data_inspection invoque ce modèle, dont l'administrateur configure centralement les paramètres et les identifiants côté Provider. En l'absence de configuration du modèle cible, les appels échouent avec une operational_error (modèle inexistant, renvoyé sous forme d'erreur HTTP 500 avec le code métier 65535).

  • pymilvus est installé. Les exemples de ce tutoriel ont été vérifiés avec pymilvus [TODO: confirm version].

Important

L'interface RESTful et gRPC partagent le port 19530 ; vous devez donc spécifier explicitement ce port, par exemple http://c-xxx.milvus.aliyuncs.com:19530. L'omission du port entraîne un retour au port 80 et provoque un délai d'expiration de connexion.

Procédure

Ce tutoriel présente deux méthodes d'intégration du garde-fou. Choisissez celle qui correspond au mode d'appel au modèle de votre application :

  • Collection avec une fonction TextTransform — Le garde-fou s'exécute lors de l'écriture de données dans une collection. Privilégiez cette méthode pour les pipelines qui inspectent puis persistent le contenu, comme la modération d'UGC avant stockage. La plupart des étapes de ce tutoriel suivent cette approche.

  • **Appel REST synchrone text_generate** — Le garde-fou s'exécute en ligne et renvoie la disposition dans la réponse. Cette option convient aux scénarios requête/réponse en temps réel, tels que la réponse interactive aux questions. L'étape 4 illustre également ce chemin. (Recommandé) Pour la réponse interactive aux questions par IA, utilisez l'appel REST synchrone text_generate. Pour le contenu devant être inspecté avant stockage, optez pour la Collection avec une fonction TextTransform.

Étape 1 : Préparer le code partagé

Le code suivant contient les paramètres de connexion, un wrapper REST, un mécanisme de compatibilité pour le type TEXTTRANSFORM et une fonction utilitaire créant une Collection dotée d'un garde-fou. Le commutateur du garde-fou correspond à l'unique ligne data_inspection située dans params.

from __future__ import annotations

import json
from typing import Any
from urllib.error import HTTPError, URLError
from urllib.request import Request, urlopen

from pymilvus import DataType, Function, FunctionType, MilvusClient
from pymilvus.exceptions import MilvusException

# ==================== Connection settings ====================
MILVUS_URI = "http://c-xxx.milvus.aliyuncs.com:19530"  # The port must be 19530
MILVUS_TOKEN = "root:xxx"
MILVUS_REST_BASE_URL = MILVUS_URI
MODEL_NAME = "<your-configured-text-model>"  # Replace with a text model already configured in the Provider

TEXTTRANSFORM_FUNCTION_TYPE = 9

# The contract identifier returned by the Provider when a safety policy is triggered.
# It is the only reliable basis for deciding whether content was blocked.
BLOCK_MARKERS = ("DataInspectionFailed", "inappropriate content")

client = MilvusClient(uri=MILVUS_URI, token=MILVUS_TOKEN)

def texttransform_function_type() -> Any:
    """Get the FunctionType for TEXTTRANSFORM; add a member dynamically when the enum is missing in older versions."""
    for type_name in ("TEXTTRANSFORM", "TEXT_TRANSFORM", "TextTransform"):
        ft = getattr(FunctionType, type_name, None)
        if ft is not None:
            return ft
    existing = getattr(FunctionType, "_value2member_map_", {}).get(TEXTTRANSFORM_FUNCTION_TYPE)
    if existing is not None:
        return existing
    extension = int.__new__(FunctionType, TEXTTRANSFORM_FUNCTION_TYPE)
    extension._name_ = "TEXTTRANSFORM"
    extension._value_ = TEXTTRANSFORM_FUNCTION_TYPE
    FunctionType._value2member_map_[TEXTTRANSFORM_FUNCTION_TYPE] = extension
    FunctionType._member_map_["TEXTTRANSFORM"] = extension
    return extension

def post_json(path: str, body: dict[str, Any], timeout: int = 120) -> tuple[int, dict[str, Any]]:
    """REST wrapper: returns (http_status, data), and still tries to parse the response body when HTTP is not 2xx."""
    request = Request(
        f"{MILVUS_REST_BASE_URL.rstrip('/')}{path}",
        data=json.dumps(body, ensure_ascii=False).encode("utf-8"),
        headers={"Authorization": f"Bearer {MILVUS_TOKEN}", "Content-Type": "application/json"},
        method="POST",
    )
    try:
        with urlopen(request, timeout=timeout) as response:
            return response.status, json.loads(response.read().decode("utf-8"))
    except HTTPError as exc:
        return exc.code, json.loads(exc.read().decode("utf-8"))

def build_guard_collection(name: str, func_name: str, in_field: str, out_field: str,
                           prompt: str, data_inspection: str) -> None:
    """Create a write-oriented Collection with a TextTransform guardrail."""
    if client.has_collection(name):
        client.drop_collection(name)

    schema = MilvusClient.create_schema(auto_id=True, enable_dynamic_field=False)
    schema.add_field("id", DataType.INT64, is_primary=True)
    schema.add_field(in_field, DataType.VARCHAR, max_length=1024)
    schema.add_field(out_field, DataType.VARCHAR, max_length=4096)
    # A Collection must have at least one vector field. This example does not run vector search,
    # so a 2-dimensional placeholder field satisfies the constraint.
    # With nullable=True declared, the field does not need to be passed on insert.
    schema.add_field("dummy_vector", DataType.FLOAT_VECTOR, dim=2, nullable=True)
    schema.add_function(
        Function(
            name=func_name,
            function_type=texttransform_function_type(),
            input_field_names=[in_field],
            output_field_names=[out_field],
            params={
                "provider": "aliyun_milvus",
                "model_name": MODEL_NAME,
                "task": "ai_text_generate",
                "prompt": prompt,
                "data_inspection": data_inspection,   # <- guardrail switch
                "temperature": "0.2",
                "enable_thinking": "false",
                "timeout_sec": "45",
            },
        )
    )
    index_params = client.prepare_index_params()
    index_params.add_index(field_name="dummy_vector", index_type="AUTOINDEX",
                           metric_type="COSINE")
    client.create_collection(collection_name=name, schema=schema, index_params=index_params)

Une Collection doit contenir au moins un champ vectoriel, faute de quoi sa création échoue avec l'erreur schema does not contain vector field. Cet exemple n'effectuant pas de recherche vectorielle, un champ vectoriel fictif à deux dimensions satisfait à cette contrainte. Il est déclaré avec nullable=True afin d'éviter de fournir une valeur lors de chaque écriture.

Étape 2 : Synthétiser les résultats d'interception en trois dispositions

Cette difficulté technique est souvent sous-estimée lors de la mise en production d'un garde-fou. Lorsqu'une politique de sécurité se déclenche, le serveur peut renvoyer une erreur HTTP, un code métier non nul ou un refus explicite sous forme de texte dans une réponse HTTP 200. Le client doit donc synthétiser les signaux observés en trois dispositions mutuellement exclusives :

Disposition Signification Action recommandée
policy_blocked Une politique de sécurité a été déclenchée ; le garde-fou fonctionne comme prévu et le résultat est attendu par le métier. Consignez un journal d'audit et renvoyez un avis de conformité à l'utilisateur. Aucune alerte opérationnelle n'est nécessaire.
manual_review La couche protocolaire ne peut pas statuer, par exemple en cas de réponse HTTP 200 avec une structure normale mais un contenu suspect. Envoyez l'échantillon dans la file d'attente de revue manuelle. « Aucune erreur signalée » ne signifie pas « passage en toute sécurité ».
operational_error Une défaillance réelle du service, telle qu'un modèle indisponible, une erreur de paramètre ou une panne réseau. Alertez l'ingénieur d'astreinte et cessez les nouvelles tentatives. Ne réessayez pas indéfiniment.
# ==================== Three-state disposition classification ====================
# Both call paths (gRPC exception / REST response body) first check the Provider contract identifier,
# then fall back to the HTTP status and business code, so the same interception yields a consistent
# disposition on both paths.

def classify_grpc(exc: MilvusException) -> str:
    """Converge a gRPC exception into a three-state disposition."""
    msg = str(exc)
    if any(marker in msg for marker in BLOCK_MARKERS):
        return "policy_blocked"      # A safety policy was triggered, which is an expected business result
    return "operational_error"       # Everything else counts as a service fault

def classify_rest(status: int, data: dict[str, Any]) -> str:
    """Converge a REST response into a three-state disposition."""
    raw = json.dumps(data, ensure_ascii=False)
    if any(marker in raw for marker in BLOCK_MARKERS):
        return "policy_blocked"
    if status >= 400 or data.get("code", 0) != 0:
        return "operational_error"
    # HTTP 200 with a normal structure: the model may have returned an explicit refusal in the body.
    # The protocol layer cannot decide, so route it to manual review instead of treating it as a safe pass.
    return "manual_review"

La fonction classify_rest adopte volontairement une posture conservatrice. Face à une réponse HTTP 200 présentant une structure normale, la couche protocolaire seule ne peut garantir l'innocuité du corps, car le modèle pourrait y avoir intégré un refus explicite. La fonction renvoie donc manual_review pour ce cas indécidable plutôt que de le valider silencieusement. Associez classify_rest à votre propre validation de réponse afin qu'une réponse confirmée comme véritable réponse métier soit traitée comme valide, et que seules les réponses restant indécises rejoignent la file de revue. Cette approche garantit la cohérence entre le tableau des scénarios, qui prévoit un « Passage » pour les entrées normales, et l'objectif de n'envoyer qu'un petit nombre d'échantillons ambigus en revue manuelle.

Pourquoi la décision doit reposer sur l'identifiant de contrat du Provider plutôt que sur le seul code de statut HTTP. Les tests ont confirmé qu'« une entrée non conforme bloquée par le garde-fou » et « une défaillance de service due à un nom de modèle inexistant » renvoient exactement la même combinaison de codes de statut :

Scénario Statut HTTP Code métier **Le corps de la réponse contient DataInspectionFailed** Disposition correcte
Entrée non conforme bloquée 500 65535 Oui policy_blocked
Nom de modèle inexistant 500 65535 Non operational_error
Paramètre obligatoire texts manquant 400 1100 Non operational_error
Entrée normale 200 0 Non Passage autorisé

Les deux premières lignes affichent des codes de statut HTTP et des codes métier identiques, ce qui empêche de distinguer un « contenu bloqué » d'un « échec de service ». Pourtant, leur signification opérationnelle diffère totalement : classer à tort un blocage de politique comme une défaillance de service transforme chaque interception de sécurité en fausse alerte de panne, ce qui finit par masquer les véritables incidents. La décision doit par conséquent s'appuyer sur l'identifiant de contrat DataInspectionFailed présent dans le corps de la réponse. Pour la même raison, évitez de dépendre de valeurs spécifiques de codes de statut HTTP, car elles peuvent varier selon les versions de la passerelle.

N'utilisez pas de mots-clés tels que « risque », « rejet » ou « impossible » pour déterminer si un contenu a été bloqué, car des textes métier légitimes peuvent également contenir ces termes et provoquer des faux positifs. Les mots-clés constituent tout au plus un signal auxiliaire et ne doivent en aucun cas modifier la disposition finale.

Étape 3 : Inspecter le contenu conforme en modes entrée et sortie

Le mode input inspecte les entrées utilisateur avant l'appel au modèle, tandis que le mode output examine les sorties du modèle avant le renvoi du résultat. Le contenu conforme traverse le système normalement.

# ==================== Step 3a: input mode, inspection before the request ====================
build_guard_collection(
    "guard_input", "inspect_customer_request", "request", "response",
    "Answer in one sentence in a customer service tone: ${request}", "input",
)
client.insert("guard_input", [{"request": "How long does a refund take to arrive after it is approved?"}])
client.flush("guard_input")
for row in client.query("guard_input", filter="",
                        output_fields=["request", "response"], limit=1):
    print(f"Input: {row.get('request')}")
    print(f"Output: {row.get('response')}")
# The guardrail was not triggered, so the content passes through and the model returns normally.
# With a jailbreak prompt instead, the model is never called and the guardrail blocks it up front.

# ==================== Step 3b: output mode, inspection before publishing model output ====================
build_guard_collection(
    "guard_output", "inspect_generated_copy", "draft_request", "publish_copy",
    "Generate a membership campaign summary suitable for publishing in an app: ${draft_request}", "output",
)
client.insert("guard_output",
              [{"draft_request": "Generate a benefits summary for Members Day in 30 words or fewer, with no exaggerated promises."}])
client.flush("guard_output")
for row in client.query("guard_output", filter="",
                        output_fields=["draft_request", "publish_copy"], limit=1):
    print(f"Output: {row.get('publish_copy')}")
# The output passed the safety inspection and enters the pending publish queue.

Les résultats suivants ont été vérifiés lors des tests :

Mode Entrée Sortie
input How long does a refund take to arrive after it is approved? After your refund is approved, the amount is usually returned to your original payment account within 1 to 7 business days. The exact arrival time depends on how quickly the payment channel processes it, so please keep an eye out for it.
output Generate a benefits summary for Members Day in 30 words or fewer, with no exaggerated promises. Members Day offers exclusive points redemption, member-only discounts, and priority customer service. Details are shown on the campaign page.

Lorsque le mode input se déclenche, le modèle n'est pas appelé ; le risque est ainsi bloqué tout en économisant le coût de l'appel au modèle. Le mode output convient aux scénarios où l'entrée est fiable et où seule l'improvisation du modèle suscite des inquiétudes.

Étape 4 : Bloquer les entrées non conformes en mode both

Utilisez both lorsqu'aucune des deux extrémités n'est fiable. L'exemple suivant vérifie l'efficacité réelle du garde-fou en envoyant une entrée de test clairement non conforme. Exécutez cette vérification d'efficacité du garde-fou avant la mise en production.

Remplacez <a clearly non-compliant test input> par une chaîne de test non conforme réelle (canari) avant d'exécuter cette étape. L'espace réservé ci-dessous est inerte et ne déclenche pas le garde-fou ; vous ne pourrez donc reproduire le résultat d'interception qu'après avoir substitué une valeur réelle.

# ==================== Step 4: both mode, double inspection at both ends ====================
# Use one clearly non-compliant test input (canary) to verify that the guardrail really blocks it.
UNSAFE_INPUT = "<a clearly non-compliant test input>"

# (Step 4-1) gRPC path: the guardrail is triggered on write
build_guard_collection("guard_both", "inspect_both", "request", "response",
                       "Answer the following: ${request}", "both")
try:
    client.insert("guard_both", [{"request": UNSAFE_INPUT}])
    client.flush("guard_both")
    rows = client.query("guard_both", filter="",
                        output_fields=["request", "response"], limit=1)
    # No error raised does not mean safely passed: route normal-structure but suspicious content to manual review
    print("Disposition: manual_review", [r.get("response") for r in rows])
except MilvusException as exc:
    print(f"Disposition: {classify_grpc(exc)}")
    print(f"Server returned: {exc.message}")

# (Step 4-2) REST path: send the same input to the synchronous interface
status, data = post_json("/v2/vectordb/ai/text_generate", {
    "model_name": MODEL_NAME,
    "texts": [UNSAFE_INPUT],
    "params": {"data_inspection": "both"},
})
disposition = classify_rest(status, data)
print(f"Observed signals: HTTP={status} provider_code={data.get('code')}")
print(f"Disposition: {disposition}")

# Route by disposition: a policy block is an expected result and needs no operations alert;
# only a service fault needs an alert, and it must not be retried indefinitely
if disposition == "policy_blocked":
    pass          # Record an audit log and return a compliance notice to the user
elif disposition == "manual_review":
    pass          # Send to the manual review queue
else:
    pass          # Alert the on-call engineer and stop retrying

Les tests ont confirmé que les deux chemins bloquent l'entrée avec succès et que le serveur renvoie un identifiant de contrat cohérent :

code: DataInspectionFailed
message: Input data may contain inappropriate content.
         For details, see: https://www.alibabacloud.com/help/zh/model-studio/error-code#inappropriate-content

Le garde-fou s'est déclenché côté entrée, l'écriture a été bloquée et le modèle n'a généré aucun contenu. Après traitement des signaux par les fonctions de classification, le chemin gRPC et le chemin REST aboutissent tous deux à la même conclusion policy_blocked.

Les tests ont également confirmé que le mode both ne bloque pas indûment les entrées métier normales : l'envoi d'une question de service client standard à la même interface a renvoyé une réponse HTTP 200 accompagnée d'une réponse complète.

Étape 5 : Journaliser les dispositions en toute sécurité

Une fois le garde-fou en production, les journaux doivent permettre de localiser les problèmes sans devenir une nouvelle surface de fuite de données. Suivez ces recommandations :

  • Ne consignez que des champs lisibles par machine et expurgés : ID de trace, phase d'inspection, statut HTTP, code provider, énumération de disposition et action de disposition.

  • Tronquez ou expurgez le texte brut et les informations personnelles sensibles. Lors de la revue, récupérez les données via un canal autorisé à l'aide de l'ID de trace plutôt que de conserver du texte brut dans les journaux métier.

  • Arrêtez le traitement et déclenchez une alerte lorsqu'une politique est activée ou qu'une operational_error survient ; ne réessayez pas indéfiniment.

  • Combinez avec AI_PII_MASK : expurgez les données avant la journalisation afin de réduire autant que possible la surface d'exposition des données sensibles.

{
  "trace_id": "req-20260808-abc123",
  "stage": "both",
  "http_status": 500,
  "provider_code": 65535,
  "disposition": "policy_blocked",
  "note": "blocked by data inspection on input side"
}

Nettoyage

Les exemples de ce tutoriel créent trois collections : guard_input, guard_output et guard_both. Une fois terminé, supprimez-les pour éliminer les données de test :

for name in ("guard_input", "guard_output", "guard_both"):
    if client.has_collection(name):
        client.drop_collection(name)

Valeur de la solution

Dimension Avant le garde-fou **Après activation de DATA_INSPECTION**
Contournements et prompts non conformes côté entrée Repose sur une revue manuelle en aval, entraînant un traitement retardé Bloqué avant l'appel au modèle
Contenu non conforme sortant côté sortie Détecté après coup et traité de manière réactive Intercepté avant le renvoi du résultat, il ne quitte donc jamais le système
Volume de revues manuelles Chaque élément fait l'objet d'une revue manuelle Seuls les quelques échantillons manual_review sont examinés
Nombre de systèmes Système métier plus un service externe de sécurité du contenu, chaînés via trois appels distants Un seul système (Milvus, avec le garde-fou attaché à l'appel)
Données et identifiants Le texte brut transite vers un service externe et l'authentification est dispersée Les données restent dans l'instance et les identifiants sont configurés centralement par le Provider

Une fois le garde-fou de sécurité du contenu réduit à un simple commutateur, il peut être choisi de manière flexible selon le scénario :

  • Réponse aux questions par service client intelligent — Ajoutez input à la génération de texte pour bloquer les prompts de contournement et les questions non conformes.

  • Copies marketing et génération de scripts — Ajoutez output à la génération de texte pour intercepter le contenu non conforme avant publication.

  • Assistants IA ouverts face au public — Utilisez both pour une double protection à chaque extrémité. Pistes d'extension envisageables :

  • **Combinaison avec AI_PII_MASK** — Expurgez d'abord, inspectez ensuite, puis journalisez, afin de réduire autant que possible la surface d'exposition des données sensibles.

  • Prise en charge de tâches supplémentaires — À mesure que davantage de tâches AI Function prendront en charge data_inspection, le même modèle input/output/both s'appliquera à de nouveaux scénarios génératifs.

  • Bouclage de la politique — Transformez les échantillons manual_review en jeu d'évaluation et ajustez continuellement l'équilibre entre faux positifs et faux négatifs afin que le garde-fou gagne en précision au fil du temps.