Ajouter des requêtes IA bornées à une application

Introduction

Une commande de résumé documentaire a besoin de limites prévisibles autour de sa dépendance IA. Vous ajouterez un client Bedrock borné à une application fournie, rejetterez les entrées trop longues avant l’inférence et traiterez les erreurs du service ou les réponses lentes sans exposer les exceptions brutes.

Vous devez connaître les bases de Python et la validation structurée du laboratoire précédent. L’interface et l’analyseur sont fournis pour vous concentrer sur les limites des requêtes. Cette nouvelle VM possède son document, son identité configurée et son quota d’inférence.

Lien avec la certification

Connecter un client Bedrock borné

Dans cette étape, vous implémenterez le client de la commande fournie et générerez un résumé structuré réel.

Placez-vous dans l’espace de travail :

cd /home/labex/project

Lisez le document et les options de commande :

cat incident.txt

/opt/labex/aws/venv/bin/python application.py --help

L’incident est INC-204. application.py lit un document et affiche un résultat JSON. Il appelle client.request_summary ; le response_parser.py fourni contrôle le motif de fin et les trois chaînes déjà étudiées. Le client.py initial indique un travail inachevé et n’envoie aucune requête.

Une limite d’entrée protège l’application avant de consommer du quota. Cet exemple accepte entre 1 et 1000 caractères non vides, fixe la sortie à 768 tokens et configure explicitement les délais de connexion et de lecture. total_max_attempts: 1 signifie une seule requête initiale, sans nouvelle tentative automatique. Le délai de lecture borne l’attente sur la connexion, pas la durée exacte de chaque action applicative.

Remplacez le client initial par cette implémentation. ClientError représente une erreur retournée par le service ; ReadTimeoutError une attente de lecture expirée. Tous deux deviennent de petits diagnostics JSON. Le résultat ne contient jamais les exceptions brutes, les en-têtes de requête ni les identifiants :

cat > client.py <<'EOF'
import boto3
from botocore.config import Config
from botocore.exceptions import BotoCoreError, ClientError, ReadTimeoutError
from response_parser import summarize_response


def request_summary(document, endpoint_url, read_timeout):
    if not document.strip() or len(document) > 1000:
        return {'status': 'rejected', 'reason': 'input_limit'}
    client = boto3.client('bedrock-runtime', endpoint_url=endpoint_url,
        config=Config(proxies={}, connect_timeout=3, read_timeout=read_timeout,
                      retries={'total_max_attempts': 1}))
    try:
        response = client.converse(
            modelId='labex.text-v1:0',
            system=[{'text': 'Summarize only facts supplied in the incident document. Return exactly one JSON object with string fields incident_id, impact and next_action. No Markdown fences, extra keys or surrounding prose. Do not turn planned work into completed work.'}],
            messages=[{'role': 'user', 'content': [{'text': document}]}],
            inferenceConfig={'maxTokens': 768, 'temperature': 0})
    except ReadTimeoutError:
        return {'status': 'unavailable', 'reason': 'read_timeout'}
    except ClientError as error:
        code = error.response.get('Error', {}).get('Code')
        reason = 'busy' if code == 'ThrottlingException' else 'service_unavailable'
        return {'status': 'unavailable', 'reason': reason}
    except BotoCoreError:
        return {'status': 'unavailable', 'reason': 'connection_failed'}
    return summarize_response(response)
EOF

Exécutez l’application sur son point d’accès Bedrock normal configuré. > accepted.json enregistre la sortie affichée :

/opt/labex/aws/venv/bin/python application.py > accepted.json

Lisez-la :

cat accepted.json

Attendez status: ok et les trois champs. Examinez leur sens par rapport au document. Développez la requête réelle terminée dans AWS View et comparez son texte. Le plafond borne les tokens générés ; la limite de caractères est une politique distincte. Un résultat en cache peut réutiliser une vraie sortie du modèle sans nouvelle consommation de crédits.

Rejeter une entrée trop longue avant l’inférence

Dans cette étape, vous confirmerez que le client rejette un document dépassant son budget d’entrée.

Le fichier oversized.txt fourni dépasse 1000 caractères. wc -m compte les caractères :

wc -m oversized.txt

Traitez ce fichier avec la même application :

/opt/labex/aws/venv/bin/python application.py --document oversized.txt > too-long.json

Ce rejet volontaire termine avec le code 2. echo $? affiche le code de la commande précédente :

echo $?

Lisez le résultat sûr :

cat too-long.json

Attendez status: rejected et reason: input_limit. Le client vérifie l’entrée avant de construire la requête d’inférence ; AWS View doit donc toujours montrer uniquement la requête précédente. Rejeter l’entrée empêche une nouvelle consommation ; supprimer un résultat n’annulerait pas une consommation passée.

Traiter une erreur de service et un délai de lecture expiré

Dans cette étape, vous testerez les limites d’erreur avec deux services locaux de test de transport explicitement identifiés.

Les points d’accès suivants renvoient volontairement une erreur ou retardent la réponse. Ils n’envoient aucune requête au modèle et ne consomment aucun crédit d’inférence. Ce sont des dépendances de test, pas des fournisseurs alternatifs d’inférence réussie.

Utilisez le cas de service indisponible sur le port 5001 :

/opt/labex/aws/venv/bin/python application.py --endpoint-url http://127.0.0.1:5001 > unavailable.json

Cet échec attendu termine avec le code 3. Examinez son diagnostic :

cat unavailable.json

Attendez status: unavailable et reason: service_unavailable, sans trace de pile, texte d’exception du SDK ou identifiants.

Le service du port 5002 attend trois secondes. Réglez la lecture à une seconde pour ce test :

/opt/labex/aws/venv/bin/python application.py --endpoint-url http://127.0.0.1:5002 --read-timeout 1 > timed-out.json

Lisez le résultat :

cat timed-out.json

Attendez status: unavailable et reason: read_timeout. Le SDK effectue une tentative. Un délai expiré ne prouve pas qu’une requête au modèle en amont a été annulée ou gratuite : l’amont réel peut terminer après que le client cesse d’attendre. Examinez requêtes en attente ou échouées et quota avant de réessayer ; n’ajoutez pas de boucle de répétition inconditionnelle.

AWS View doit encore contenir uniquement la requête réelle de l’étape 1. Les 150 secondes de lecture normales constituent un choix fini pour cet exercice ; une application réelle doit choisir délais, politique de répétition et retour utilisateur selon son budget de latence. La référence officielle de Config explique les contrôles séparés de connexion, lecture et tentatives.

Supprimer les sorties de test et garder l’application fonctionnelle

Dans cette étape, vous nettoierez quatre fichiers de résultats locaux en conservant le client fonctionnel et l’application fournie.

Les contrôles fonctionnels et d’échec doivent passer avant le nettoyage. Supprimez uniquement les sorties nommées :

rm accepted.json too-long.json unavailable.json timed-out.json

Listez les fichiers restants :

ls

Conservez application.py, client.py, response_parser.py, le document et les cas de test. Converse n’a créé aucune charge persistante ; supprimer les sorties locales ne rend pas les crédits. Le code reste disponible pour pratiquer jusqu’à la fin de cette VM.

Résumé

Vous avez connecté une requête Bedrock réelle à la commande fournie, borné entrée et sortie, désactivé les répétitions automatiques et configuré des attentes finies. Vous avez testé erreur et délai sans remplacer l’inférence par un succès prédéfini, retourné des diagnostics sûrs et supprimé uniquement les sorties locales.