FR ▾
Commencer maintenant

IA sans censure pour les développeurs : créez sans refus

L'IA sans censure pour les développeurs déplace les règles de contenu du modèle vers votre application. Cela vous donne de la liberté, mais aussi la charge d'écrire et d'appliquer ces règles.

Dernière mise à jour

Blocs de données passant par des portes de checkpoint avant d'atteindre un terminal, illustrant une couche de modération

Faits clés

  • Écrivez les règles de votre produit dans un prompt système et vérifiez-les dans le code.
  • Ajoutez vos propres vérifications d'entrée et de sortie, car le modèle ne fera pas tout pour vous.
  • Journalisez les IDs de requête, le nombre de tokens et un ID utilisateur haché, pas les conversations brutes, sauf si vous en avez besoin.
  • Vous restez responsable de vos utilisateurs et de votre juridiction. Tout contenu sexuel impliquant des mineurs est interdit.

Ce qui change lorsque le modèle cesse de refuser

Avec un assistant grand public, le fournisseur décide de ce qui est acceptable et le modèle décline le reste. Avec un modèle sans censure, ajusté pour répondre sans refus de contenu pour un usage adulte légal, cette couche disparaît. L'IA sans censure pour les développeurs est utile pour les outils de fiction, les applications compagnons, la recherche sur le comportement des modèles et tout produit où les refus grand public gênent le travail légal.

Ce qui remplace le filtre du fournisseur est votre propre conception. Vous décidez qui peut utiliser l'application, ce que le modèle peut écrire, et ce que vous faites en cas de problème. Cet article couvre quatre aspects de ce travail : le prompt système, une couche de modération, la journalisation et vos responsabilités.

Commencez par un prompt système qui énonce les règles

Un system prompt est votre premier et le moins cher des contrôles. Rédigez-le comme une courte politique, en phrases simples, et gardez-le stable entre les versions pour que le comportement soit facile à raisonner.

  • Rôle et cadre. Qui est l'assistant et à quoi sert le produit.
  • Public. Indiquez que tous les utilisateurs et tous les personnages sont adultes.
  • Limites. Listez ce que l'assistant ne doit pas écrire dans votre produit, par exemple le contenu impliquant des mineurs, des personnes privées réelles, ou des instructions pour nuire à autrui.
  • Format. Longueur, ton, langue, que faire lorsqu'on vous pose une question hors sujet.
SYSTEM = '''You are the narrator of an interactive fiction app for adult readers.
All characters are adults. Never write sexual content involving minors.
Do not write about real, named private individuals.
If a request is outside the story, say so briefly and return to the scene.
Keep replies under 200 words.'''

Un system prompt est un guide, pas une garantie. Le modèle peut dériver, et les utilisateurs peuvent le repousser. C'est pourquoi la couche suivante existe.

Construisez une couche de modération autour du modèle

Vérifiez le texte deux fois : avant qu'il n'atteigne le modèle et après la réponse du modèle. Des règles bon marché capturent les cas évidents, et un second appel au modèle peut juger les cas ambigus. Le mode JSON facilite l'analyse du verdict.

import json
from openai import OpenAI

client = OpenAI(base_url="https://api.bestuncensored.com/v1", api_key="YOUR_KEY")

BLOCKLIST = ["example banned phrase"]  # your own rules

JUDGE = '''Classify the text. Reply with JSON: {"verdict": "allow" or "block", "reason": "short"}.
Block if it sexualizes anyone under 18, or asks for real-world harm.'''

def judge(text):
    r = client.chat.completions.create(
        model="uncensored",
        messages=[{"role": "system", "content": JUDGE}, {"role": "user", "content": text}],
        response_format={"type": "json_object"},
        temperature=0,
    )
    return json.loads(r.choices[0].message.content)

def safe_reply(user_text, system):
    low = user_text.lower()
    if any(b in low for b in BLOCKLIST) or judge(user_text)["verdict"] == "block":
        return "That request is outside what this app allows."
    r = client.chat.completions.create(
        model="uncensored",
        messages=[{"role": "system", "content": system}, {"role": "user", "content": user_text}],
    )
    out = r.choices[0].message.content
    if judge(out)["verdict"] == "block":
        return "That reply was withheld by the app's content rules."
    return out

Les appels de jugement coûtent des tokens comme tout appel : à $0,15 par 1M d'entrée et $0,50 par 1M de sortie, une vérification de 300 tokens avec un verdict de 20 tokens coûte 300 x $0,15 / 1 000 000 + 20 x $0,50 / 1 000 000 = $0,000045 + $0,00001 = $0,000055. Deux vérifications par message ajoutent $0,00011, ce qui est faible par rapport à la réponse. Aucun filtre n'est parfait, alors gardez un bouton de signalement et examinez les éléments signalés.

Journalisation sans accumulation

Vous avez besoin de journaux pour déboguer, gérer les rapports d'abus et surveiller les coûts. Vous n'avez pas besoin de chaque conversation en texte brut, et les stocker crée des risques pour vous et vos utilisateurs. Les prompts envoyés à cette API ne sont pas utilisés pour l'entraînement, mais vos propres journaux sont votre responsabilité.

Une bonne pratique par défaut est de journaliser les métadonnées : l'heure, un ID utilisateur haché, l'en-tête de réponse X-Request-Id, le nombre de tokens et le verdict de modération. Stockez le texte complet uniquement pour les éléments signalés, avec une courte période de rétention.

import hashlib, logging

log = logging.getLogger("llm")

def logged_call(user_id, messages):
    raw = client.chat.completions.with_raw_response.create(
        model="uncensored", messages=messages
    )
    resp = raw.parse()
    log.info(
        "user=%s req=%s in=%s out=%s balance=%s",
        hashlib.sha256(user_id.encode()).hexdigest()[:12],
        raw.headers.get("x-request-id"),
        resp.usage.prompt_tokens,
        resp.usage.completion_tokens,
        raw.headers.get("x-balance-usd"),
    )
    return resp.choices[0].message.content

L'ID de requête est ce que vous citez si vous contactez un jour support au sujet d'un appel spécifique.

Responsabilités que vous conservez

Ce sont des informations générales, pas des conseils juridiques. Consultez un avocat pour votre cas spécifique. Ces points s'appliquent à la plupart des produits construits sur un modèle sans censure :

  • La ligne dure. Le contenu sexuel impliquant des mineurs n'est jamais autorisé sur ce service, et aucun prompt système ne change cela. Traitez-le comme une ligne dans votre propre produit aussi.
  • Contrôle d'âge. Si votre produit contient du contenu pour adultes, vérifiez ou au moins restreignez l'accès par âge d'une manière adaptée aux endroits où vous opérez.
  • Loi locale. Les règles sur le contenu pour adultes, la protection des données et la conservation des enregistrements varient selon les pays et les États. Elles s'appliquent à vous et à vos utilisateurs, où que l'API s'exécute.
  • Conditions et confidentialité. Publiez vos propres conditions et politique de confidentialité. Lisez aussi celles du fournisseur : conditions et confidentialité.
  • Clés. Gardez les clés API sur votre serveur, jamais dans un navigateur ou un bundle d'application.

Abus, signalements et limites de votre propre compte

Une fois que les vrais utilisateurs arrivent, certains essayeront de pousser le produit au-delà de vos règles. Prévoyez cela dès le premier jour.

  • Limites par utilisateur. Limitez les messages par jour et les requêtes par minute par compte. Cela protège votre budget et ralentit les abus automatisés. Vos propres limites doivent être inférieures à celles de l'API : une clé complète permet 300 requêtes par minute pour tous les utilisateurs.
  • Un bouton de signalement. Permettez aux utilisateurs de signaler une réponse. Stockez l'ID de requête et le texte de l'échange signalé, et examinez la file d'attente régulièrement.
  • Escalade. Décidez à l'avance ce qui se passe après des violations répétées : un avertissement, un blocage temporaire, une interdiction. Écrivez-le dans vos conditions.
  • Hygiène des clés. Une fois votre compte rechargé, vous pouvez conserver jusqu'à 5 clés libellées, donc utilisez-en une par environnement. Ne livrez jamais une clé dans le code client. Régénérez une clé sur la page des clés si elle a pu être exposée ; l'ancienne cesse de fonctionner immédiatement.

Votre file d'attente vous montrera également où le prompt système est faible. Lorsque le même type de sortie signalée apparaît trois fois, modifiez le prompt ou le filtre, puis relancez votre ensemble de tests pour vous assurer que rien d'autre n'a été cassé. Traitez les prompts comme du code : gardez-les dans un contrôle de version et notez à quoi servait chaque modification.

Planifiez les limites et les échecs

Le code de production a besoin d'un mécanisme de backoff. Une clé complète permet 8 requêtes simultanées et 300 requêtes par minute. Au-delà d'une limite, l'API renvoie un HTTP 429 avec le code rate_limited ou concurrency, et en cas de surcharge temporaire, un 429 avec Retry-After: 5. Respectez cet en-tête. Si vous effectuez un appel de vérification (juge) et un appel de réponse par message, les deux comptent dans les limites, donc dimensionnez votre file d'attente pour le double des requêtes.

Les requêtes échouées ou refusées ne sont pas facturées, donc les nouvelles tentatives ne coûtent rien pour les tentatives échouées. La documentation liste les paramètres, et vous pouvez tout essayer avec le crédit d'essai depuis la page de clé API. Pour les options dans cet espace, voir Comparaison des options d'IA sans censure.

Une revue avant le lancement

Avant l'arrivée des vrais utilisateurs, parcourez une session scriptée comme le ferait un attaquant. Essayez de faire produire à l'application quelque chose que vos règles interdisent, en demandant directement, en jouant un rôle, en divisant la requête sur plusieurs tours et en collant du texte contenant des instructions. Enregistrez ce qui passe au travers et corrigez-le à la couche appropriée.

  • Si le modèle ignore une règle dans le prompt système, serrez le libellé et ajoutez une vérification dans le code.
  • Si une vérification bloque trop de contenu légal, assouplissez la règle ou ajoutez un chemin d'autorisation, et mesurez le taux de faux blocs sur un échantillon de prompts réels.
  • Si le problème n'apparaît que dans les longues conversations, testez avec un historique complet, car les règles dérivent à mesure que le contexte augmente. Une fenêtre de 100 000 tokens vous donne de la marge pour garder les règles près du haut et répéter un court rappel vers la fin.

Répétez cette revue chaque fois que vous modifiez le prompt, le filtre ou le paramètre du modèle. Gardez les cas de test dans un fichier et exécutez-les comme une vérification automatisée, afin qu'un changement qui casse une règle échoue avant le déploiement.

FAQ technique

Obtenez votre clé API

Inscrivez-vous, récupérez votre clé et mettez à jour l'URL de votre endpoint. Simple.

Un modèle sans censure supprime-t-il le besoin de modération ?
    Non. Il supprime les refus du fournisseur, les règles deviennent donc les vôtres. Ajoutez des règles de prompt système et des vérifications d'entrée et de sortie adaptées à votre produit.
Puis-je utiliser un second appel de modèle comme filtre ?
    Oui. Utilisez le mode JSON avec une instruction courte et une température faible, puis analysez le verdict. Chaque vérification coûte un petit nombre de tokens.
Mes prompts sont-ils utilisés pour l'entraînement ?
    Non. Les prompts ne sont pas utilisés pour l'entraînement.
Qu'est-ce qui n'est jamais autorisé ?
    Contenu sexuel impliquant des mineurs. Le service est destiné à un usage adulte légal.
Dois-je enregistrer les conversations complètes ?
    Uniquement lorsque vous avez une raison claire. Les métadonnées telles que l'ID de requête et le nombre de tokens suffisent généralement, le texte complet étant conservé uniquement pour les éléments signalés.