Adicionar solicitações de IA com limites a uma aplicação

Introdução

Um comando de resumo de documentos precisa de limites previsíveis para sua dependência de IA. Você adicionará um cliente Bedrock com limites a uma aplicação fornecida, rejeitará entradas grandes demais antes da inferência e tratará falhas do serviço ou respostas lentas sem expor exceções brutas.

Você deve conhecer os fundamentos de Python e a validação de saída estruturada ensinada no laboratório guiado anterior. A interface do comando e o analisador de respostas são fornecidos para que você se concentre nos limites das solicitações. Esta nova VM tem seu próprio documento, identidade configurada e cota de inferência.

Relevância para a certificação

Conectar um cliente Bedrock com limites

Nesta etapa, você implementará o cliente do comando fornecido e gerará um resumo estruturado real.

Comece no ambiente de trabalho:

cd /home/labex/project

Leia o documento de origem e as opções do comando:

cat incident.txt

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

O incidente é INC-204. application.py lê um documento e imprime um resultado JSON. Ele chama client.request_summary; o response_parser.py fornecido verifica o motivo de conclusão e os três campos de string praticados anteriormente. O client.py inicial informa que o trabalho está incompleto e não envia solicitações.

Um limite de entrada protege a aplicação antes de consumir a cota de inferência. Este exemplo aceita de 1 a 1000 caracteres não vazios, fixa o limite de saída do modelo em 768 tokens e usa tempos limite explícitos de conexão e leitura do SDK. total_max_attempts: 1 significa uma solicitação inicial sem novas tentativas automáticas. Um tempo limite de leitura limita a espera na conexão; não promete que toda ação da aplicação termine exatamente naquele instante.

Substitua o cliente inicial por esta implementação. ClientError representa uma resposta do serviço; ReadTimeoutError identifica uma espera de leitura que expirou. Ambos se tornam pequenos resultados JSON de diagnóstico. Exceções brutas, cabeçalhos de solicitação e credenciais nunca são incluídos no resultado:

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

Execute a aplicação com seu endpoint Bedrock normal configurado. > accepted.json salva a saída impressa:

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

Leia o arquivo:

cat accepted.json

Espere status: ok com os três campos do resumo. Revise seu significado comparando-o com o documento. No AWS View superior, expanda a solicitação real concluída e compare seu texto. O limite de saída controla os tokens gerados, enquanto o limite de caracteres de entrada é uma política separada da aplicação. Uma resposta em cache pode reutilizar a saída real do modelo sem outra cobrança de créditos.

Rejeitar entradas grandes demais antes da inferência

Nesta etapa, você confirmará que o cliente rejeita um documento fora de seu limite de entrada.

O oversized.txt fornecido contém mais de 1000 caracteres. wc -m conta caracteres:

wc -m oversized.txt

Envie esse arquivo pela mesma aplicação:

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

Essa rejeição intencional termina com o código 2. echo $? imprime o código de saída do comando anterior:

echo $?

Leia o resultado seguro:

cat too-long.json

Espere status: rejected e reason: input_limit. O cliente verifica a entrada antes de construir uma solicitação de inferência, portanto o AWS View ainda deve conter apenas a solicitação concluída anteriormente. Rejeitar a entrada evita um novo consumo pelo modelo; excluir um arquivo de resultado não desfaz uma cobrança anterior.

Tratar falhas do serviço e tempo limite de leitura

Nesta etapa, você testará o tratamento de erros do cliente usando dois serviços locais explícitos de teste de transporte.

Os endpoints abaixo retornam deliberadamente um erro de serviço ou atrasam uma resposta. Eles não enviam solicitações ao modelo nem consomem créditos de inferência. São dependências de teste, não provedores alternativos de inferência bem-sucedida.

Use o serviço de teste de indisponibilidade na porta 5001:

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

Essa falha esperada termina com o código 3. Examine seu resultado de diagnóstico:

cat unavailable.json

Espere status: unavailable e reason: service_unavailable, sem rastreamento de pilha, texto de exceção do SDK ou credenciais.

O serviço de teste na porta 5002 espera três segundos. Altere o tempo limite de leitura para um segundo neste teste:

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

Leia o resultado:

cat timed-out.json

Espere status: unavailable e reason: read_timeout. O SDK faz uma única tentativa. Um tempo limite não prova que uma solicitação ao modelo no serviço upstream foi cancelada ou não teve custo: um serviço real ainda pode terminar depois que o cliente parar de esperar. Examine as solicitações pendentes ou com falha e a cota antes de tentar novamente; não adicione um ciclo de novas tentativas incondicional.

O AWS View ainda deve conter apenas a solicitação real da etapa 1. O tempo limite de leitura de 150 segundos do comando normal é uma escolha finita para este exercício; uma aplicação real deve escolher tempos limite, política de novas tentativas e informações ao usuário conforme seu orçamento de latência. A referência oficial de Config explica os controles separados de conexão, leitura e tentativas.

Remover as saídas de teste e manter a aplicação funcional

Nesta etapa, você limpará seus quatro arquivos locais de resultados, mantendo o cliente funcional e a aplicação fornecida.

As verificações funcionais e de falha devem passar antes da limpeza. Remova apenas as saídas indicadas:

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

Liste os arquivos restantes:

ls

Mantenha application.py, client.py, response_parser.py, o documento e os dados de teste. Converse não criou uma carga de trabalho persistente na nuvem; remover saídas locais não devolve créditos. O código da aplicação permanece disponível para outras práticas até que esta VM termine.

Resumo

Você conectou uma solicitação real do Bedrock a um comando de resumo fornecido, limitou a entrada e a saída gerada, desativou novas tentativas automáticas e configurou esperas finitas de conexão e leitura. Testou falhas do serviço e tempo limite sem substituir a inferência por um sucesso falso, retornou diagnósticos seguros e removeu apenas as saídas locais de teste.