Bedrock으로 지원 답변 생성하기

소개

지원팀은 중복 청구 신고에 대한 답변 초안이 필요합니다. 티켓을 Bedrock Runtime에 보내고, 작성 지침을 개선하며, 생성된 답변과 토큰 사용량을 출력 한도와 비교합니다. 새 LabEx VM의 AWS CLI는 이미 설정되어 있습니다. 제공된 합성 티켓만 사용하세요.

명령 실행과 텍스트 파일 읽기를 알아야 합니다. 이 작업은 초안을 생성하고 검토하는 것이며, 고객에게 메시지를 보내거나 결제 기록을 바꾸는 작업이 아닙니다.

자격증 관련성

지원 답변 초안 작성하기

이 단계에서는 사용 가능한 텍스트 모델을 선택하고 지원 티켓을 Bedrock Runtime에 보냅니다.

위쪽 AWS View는 모델과 실제 요청 결과를 표시합니다. 아래쪽 Terminal에 명령을 입력합니다. 요청 전에는 답변이 없습니다. 요청 후에는 대기 중인 요청, 이어서 응답과 사용량 및 잔여 한도가 표시됩니다.

Bedrock은 여러 작업의 텍스트를 생성할 수 있는 기반 모델에 대한 접근을 제공합니다. 모델 식별자로 모델을 선택합니다. Converse는 지원되는 대화 모델의 공통 요청 형식입니다. 여기서는 작업 공간에서 사용 가능한 텍스트 모델을 사용합니다.

연습 디렉터리에서 시작합니다. cd는 Terminal의 현재 디렉터리를 바꿉니다:

cd /home/labex/project

텍스트를 출력하는 모델을 나열합니다. --by-output-modality TEXT는 목록을 필터링하고, --query는 식별자와 읽기 쉬운 이름을 선택하며, --output table은 표로 표시합니다:

aws bedrock list-foundation-models \
  --by-output-modality TEXT \
  --query 'modelSummaries[].[modelId,modelName]' \
  --output table

표에는 다음에 사용할 labex.text-v1:0가 있습니다. 카탈로그 항목은 모델을 설명하며, 추론 요청이 이미 실행되었다는 뜻은 아닙니다.

Converse 요청에는 modelId, messages 목록, 선택적 추론 설정이 있습니다. 각 메시지는 role과 콘텐츠 블록을 갖습니다. user 메시지는 질문이나 작업을 담고 텍스트 블록은 text 필드를 사용합니다. maxTokens는 생성 출력의 상한이며 temperature는 샘플링 변동을 조절합니다. 낮은 값이 변동을 줄일 수 있지만 정확하거나 동일한 답변을 보장하지는 않습니다.

JSON 요청을 만듭니다. cat > request.json은 파일을 작성하고, <<'EOF'는 여러 줄을 그대로 입력하는 시작 표시이며 마지막 EOF가 끝냅니다. 지정된 연습 파일만 교체합니다:

cat > request.json <<'EOF'
{
  "modelId": "labex.text-v1:0",
  "messages": [
    {
      "role": "user",
      "content": [{"text": "Customer ticket Q-42: the customer reports that invoice Q-42 was charged twice. Draft an English support reply in two sentences."}]
    }
  ],
  "inferenceConfig": {"maxTokens": 512, "temperature": 0}
}
EOF

bedrock-runtime converse로 요청을 보냅니다. --cli-input-json file://request.json은 파일에서 필드를 읽습니다. 마지막 > reply.json은 JSON 응답을 출력하는 대신 저장합니다:

aws bedrock-runtime converse \
  --cli-input-json file://request.json \
  > reply.json

Terminal 프롬프트가 돌아올 때까지 기다립니다. 텍스트 생성에는 보통 몇 초가 걸립니다. 첫 요청이 대기 중일 때 다른 요청을 실행하지 마세요.

응답을 읽습니다:

cat reply.json

output.message.role: "assistant"와 비어 있지 않은 text 블록을 찾습니다. usage는 처리한 토큰을, metrics.latencyMs는 밀리초 단위 응답 시간을 알려줍니다. Terminal 위의 AWS View에서 완료된 요청을 펼쳐 파일과 비교합니다.

초안을 주의 깊게 읽으세요. 조사를 시작했다거나 환불을 완료했거나 청구를 확인했다고 주장하나요? 티켓에는 그런 사실이 없습니다. 유창한 응답도 세부 사항을 지어낼 수 있으므로 다음에 지침을 구체화합니다. 생성된 문장을 완료된 결제 작업으로 받아들이지 마세요.

작성 지침 개선하기

이 단계에서는 명확한 지침을 추가하고 같은 신고 사실로 새 초안을 생성합니다.

system 필드는 작업과 문체 지침을 제공합니다. 티켓은 사용자 메시지에 두고 작성 제약은 시스템 메시지에 넣습니다. 구체적 지침은 불필요한 내용을 줄일 수 있지만 응답 검토는 여전히 필요합니다.

원래 초안을 비교용으로 남기도록 별도 요청을 만듭니다:

cat > revised-request.json <<'EOF'
{
  "modelId": "labex.text-v1:0",
  "system": [
    {"text": "You draft customer-support replies. Use only the facts in the ticket. Write two concise English sentences. Acknowledge the customer's report and ask for information needed to verify it. Do not claim that a charge was confirmed, an investigation started or a refund issued."}
  ],
  "messages": [
    {
      "role": "user",
      "content": [{"text": "Customer ticket Q-42: the customer reports that invoice Q-42 was charged twice. No billing check or refund has been completed. Draft a reply."}]
    }
  ],
  "inferenceConfig": {"maxTokens": 512, "temperature": 0}
}
EOF

수정된 초안을 생성합니다:

aws bedrock-runtime converse \
  --cli-input-json file://revised-request.json \
  > revised-reply.json

Python 표준 JSON 포맷 도구로 저장된 응답을 확인합니다. 이 도구는 유효한 JSON인지 확인하고 읽기 좋게 표시합니다:

python3 -m json.tool revised-reply.json

위쪽 AWS View에서 새 완료 요청을 펼칩니다. 두 초안을 티켓과 비교하세요. 수정된 요청은 기대를 명확히 해야 하지만, 이 응답이 따랐는지는 사람이 판단해야 합니다. 지어낸 작업이 있다면 그 문장을 고객 답변에 사용하지 마세요.

요청은 독립적입니다. 같은 모델을 다시 사용해도 이전 응답을 대화 기록으로 자동 전송하지 않습니다. 대화를 이어가려면 이전 사용자와 어시스턴트 메시지를 messages에 명시적으로 포함해야 합니다.

토큰 사용량과 출력 한도 확인하기

이 단계에서는 같은 작성 작업을 더 작은 출력 한도로 보내 실제 사용량을 확인합니다.

토큰은 모델이 처리하는 텍스트 단위이며 반드시 한 단어는 아닙니다. 입력 토큰에는 작업, 시스템 지침, 제공된 기록이 포함됩니다. 출력 토큰은 모델이 보고한 생성 토큰이며 내부 추론이 포함될 수 있습니다. 반환된 totalTokens는 입력과 출력의 합입니다.

maxTokens는 상한이며 정확히 그 수만큼 생성하라는 요청이 아닙니다. 모델은 먼저 끝날 수 있습니다. 512 대신 384 토큰 상한으로 요청을 만듭니다:

cat > bounded-request.json <<'EOF'
{
  "modelId": "labex.text-v1:0",
  "system": [
    {"text": "You draft customer-support replies. Use only the facts in the ticket. Write two concise English sentences. Acknowledge the customer's report and ask for information needed to verify it. Do not claim that a charge was confirmed, an investigation started or a refund issued."}
  ],
  "messages": [
    {
      "role": "user",
      "content": [{"text": "Customer ticket Q-42: the customer reports that invoice Q-42 was charged twice. No billing check or refund has been completed. Draft a reply."}]
    }
  ],
  "inferenceConfig": {"maxTokens": 384, "temperature": 0}
}
EOF

보내고 응답을 저장합니다:

aws bedrock-runtime converse \
  --cli-input-json file://bounded-request.json \
  > bounded-reply.json

결과를 확인합니다:

python3 -m json.tool bounded-reply.json

usage.outputTokens를 384 상한과 비교합니다. stopReason: "end_turn"은 정상 종료, "max_tokens"는 상한 도달을 뜻하므로 텍스트가 미완성일 수 있습니다. 부분 답변을 완성된 문서라고 가정하지 마세요.

AWS View는 같은 사용량과 잔여 credits를 표시합니다. Credits는 모델별 입출력 소비를 반영하므로 토큰 수만으로 모든 모델의 공통 가격을 정할 수 없습니다. 반복 요청은 캐시된 결과를 사용할 수 있어 사용량이 있어도 credits가 그대로일 수 있습니다. 한도는 요청을 제한하지만 더 작은 한도가 이번 짧은 답변에서 모든 이전 답변보다 적은 토큰을 보장하지는 않습니다.

요청이 실패하거나 사용량이 불확실하다면 재시도 전에 오류를 확인합니다. 불확실한 요청은 예약 한도를 유지할 수 있고 다른 요청은 추가 소비를 만들 수 있습니다. 이러한 애플리케이션 처리는 이후에 배웁니다.

연습 파일 정리하기

이 단계에서는 초안 검토 후 로컬 요청과 응답 파일을 삭제합니다.

Converse는 추론 요청을 보내며 삭제할 서버나 데이터베이스를 만들지 않습니다. 여섯 JSON 파일은 로컬 연습 산출물입니다. 삭제해도 토큰 사용량은 취소되지 않고 소비한 credits는 돌아오지 않습니다.

rm은 지정 파일을 삭제합니다. 다음 이름을 정확히 사용하고 다른 프로젝트 파일은 보존합니다:

rm request.json reply.json revised-request.json revised-reply.json bounded-request.json bounded-reply.json

남은 표시 가능한 작업 공간 항목을 나열합니다:

ls

여섯 파일이 없어야 합니다. AWS View는 이 VM의 실제 완료 결과와 사용량을 유지합니다. 파일 삭제로 실패가 성공이 되거나 소비가 사라지지는 않습니다.

요약

Bedrock Converse로 실제 텍스트 요청을 보내고 시스템 지침을 개선했으며, 응답과 사용량을 확인하고 출력을 제한한 뒤 로컬 파일을 삭제했습니다. 그럴듯한 초안과 검증된 업무 사실도 구분했습니다. 응답은 사용 전에 검토해야 합니다.

자세한 내용은 AWS 공식 문서를 참고하세요: Converse 메시지, 지침 및 추론 설정; Converse 응답 내용, 중지 사유 및 사용량.