Tác giả: Hasan Shojaei, Bommi Shin, Krishnan Gopalakrishnan, Anuja Narwadkar, và Sunita Koppar
Ngày phát hành: 15 JAN 2026
Chuyên mục: Amazon Bedrock, Amazon Bedrock AgentCore, Amazon Bedrock Guardrails, Amazon Machine Learning, Artificial Intelligence

Các doanh nghiệp muốn tự động hóa quy trình bằng các tác nhân AI hoặc nâng cao năng suất của nhân viên bằng các trợ lý AI dựa trên trò chuyện cần thực thi các biện pháp bảo vệ toàn diện và kiểm soát kiểm toán để sử dụng AI một cách có trách nhiệm và xử lý dữ liệu nhạy cảm bằng các mô hình ngôn ngữ lớn (LLM). Nhiều doanh nghiệp đã phát triển một cổng AI tạo sinh tùy chỉnh hoặc đã áp dụng một giải pháp có sẵn (như LiteLLM hoặc Kong AI Gateway) để cung cấp cho các chuyên gia và nhà phát triển AI của họ quyền truy cập vào các LLM từ các nhà cung cấp khác nhau. Tuy nhiên, việc thực thi và duy trì các chính sách nhất quán về an toàn prompt và bảo vệ dữ liệu nhạy cảm trên một danh sách LLM ngày càng tăng từ nhiều nhà cung cấp khác nhau ở quy mô lớn là một thách thức.

Trong bài đăng này, chúng tôi trình bày cách bạn có thể giải quyết những thách thức này bằng cách thêm các biện pháp bảo vệ tập trung vào một cổng AI tạo sinh đa nhà cung cấp tùy chỉnh bằng cách sử dụng Amazon Bedrock Guardrails. Amazon Bedrock Guardrails cung cấp một bộ tính năng an toàn giúp các tổ chức xây dựng các ứng dụng AI tạo sinh có trách nhiệm ở quy mô lớn. Bạn sẽ tìm hiểu cách sử dụng API Amazon Bedrock ApplyGuardrail để giúp thực thi các chính sách nhất quán về an toàn prompt và bảo vệ dữ liệu nhạy cảm cho các LLM từ cả Amazon Bedrock và các nhà cung cấp bên thứ ba như Microsoft Azure OpenAI. Giải pháp được đề xuất cung cấp thêm các lợi ích về ghi nhật ký và giám sát tập trung, phân tích và cơ chế tính phí nội bộ (chargeback).

Tổng quan giải pháp

Có một số yêu cầu bạn cần đáp ứng để bảo vệ các ứng dụng AI tạo sinh bằng các guardrail tập trung. Đầu tiên, các tổ chức cần một thiết lập cơ sở hạ tầng mạnh mẽ và có khả năng mở rộng cho cổng AI tạo sinh và các thành phần guardrail của nó. Giải pháp cũng cần một hệ thống ghi nhật ký và giám sát toàn diện để theo dõi các tương tác AI và khả năng phân tích để đánh giá các mẫu sử dụng và tuân thủ. Để bảo vệ dữ liệu nhạy cảm, các tổ chức cần thiết lập các chính sách quản trị dữ liệu rõ ràng và triển khai các kiểm soát an toàn thích hợp. Ngoài ra, họ cần phát triển hoặc tích hợp một cơ chế chargeback để theo dõi và phân bổ chi phí sử dụng AI giữa các phòng ban hoặc dự án khác nhau. Kiến thức về các yêu cầu quy định cụ thể cho ngành của họ là rất quan trọng để đảm bảo các guardrail được cấu hình đúng cách để đáp ứng các tiêu chuẩn tuân thủ.

Sơ đồ sau đây minh họa khái niệm về giải pháp được đề xuất của chúng tôi. Quy trình làm việc bắt đầu khi người dùng được xác thực gửi các yêu cầu HTTPS đến cổng AI tạo sinh, một ứng dụng tập trung chạy trên Amazon Elastic Container Service (Amazon ECS) đóng vai trò là giao diện chính cho các tương tác LLM. Trong logic ứng dụng của cổng AI tạo sinh, mỗi yêu cầu đến đầu tiên được chuyển tiếp đến API ApplyGuardrail của Amazon Bedrock để sàng lọc nội dung. Cổng AI tạo sinh sau đó đánh giá nội dung dựa trên các cấu hình được xác định trước, đưa ra các quyết định quan trọng để chặn hoàn toàn yêu cầu, che giấu thông tin nhạy cảm hoặc cho phép nó tiếp tục mà không sửa đổi.

Quá trình đánh giá này, không thể thiếu đối với chức năng của cổng AI tạo sinh, tạo điều kiện tuân thủ các hướng dẫn an toàn và tuân thủ đã thiết lập. Đối với các yêu cầu vượt qua quá trình sàng lọc này, logic cổng AI tạo sinh sẽ xác định nhà cung cấp LLM thích hợp (hoặc Amazon Bedrock hoặc dịch vụ bên thứ ba) dựa trên thông số kỹ thuật của người dùng. Nội dung đã được sàng lọc sau đó được chuyển tiếp đến LLM đã chọn để xử lý. Cuối cùng, cổng AI tạo sinh nhận phản hồi của LLM và trả lại cho người dùng, hoàn thành chu trình tương tác. Luồng phản hồi tuân theo hai đường dẫn riêng biệt: các yêu cầu bị chặn dẫn đến việc người dùng nhận được thông báo nội dung bị chặn, và các yêu cầu được phê duyệt sẽ cung cấp phản hồi của mô hình với việc che giấu nội dung cần thiết được áp dụng cho prompt của người dùng. Trong quá trình triển khai của chúng tôi, các guardrail chỉ được áp dụng cho đầu vào hoặc prompt chứ không phải cho các phản hồi của LLM. Quy trình được sắp xếp hợp lý này cung cấp một cách tiếp cận thống nhất để truy cập, bảo mật và tuân thủ LLM cho cả Amazon Bedrock và các nhà cung cấp bên thứ ba.

Ứng dụng cổng AI tạo sinh được lưu trữ trên AWS Fargate, và nó được xây dựng bằng FastAPI. Ứng dụng tương tác với các dịch vụ Amazon Web Services (AWS) khác như Amazon Simple Storage Service (Amazon S3), Amazon Bedrock, Amazon Kinesis và Amazon Data Firehose. Giải pháp bao gồm một lớp lưu trữ dữ liệu mạnh mẽ ghi lại các chi tiết tương tác và lưu trữ chúng trên Amazon S3 thông qua Amazon Kinesis Data Streams và Amazon Data Firehose. Dữ liệu được lưu trữ bao gồm các yêu cầu và phản hồi đã được làm sạch, thông tin giao dịch, siêu dữ liệu guardrail và nội dung bị chặn với siêu dữ liệu liên quan. Việc ghi nhật ký toàn diện này tạo điều kiện cho khả năng kiểm toán đầy đủ và cho phép cải tiến liên tục các cơ chế guardrail.

Các thành phần giải pháp

Khả năng mở rộng của giải pháp được đạt được bằng cách sử dụng các công cụ và công nghệ sau:

• nginx để cung cấp hiệu suất và độ ổn định tối đa của ứng dụng bằng cách cân bằng tải các yêu cầu trong mỗi container.
• Gunicorn, một máy chủ HTTP Python Web Server Gateway Interface (WSGI) thường được sử dụng để phục vụ các ứng dụng web Python trong môi trường sản xuất. Đây là một máy chủ hiệu suất cao có thể xử lý nhiều quy trình worker và các yêu cầu đồng thời một cách hiệu quả. Gunicorn chỉ hỗ trợ giao tiếp đồng bộ nhưng có chức năng quản lý quy trình mạnh mẽ.
• Uvicorn để cung cấp khả năng xử lý yêu cầu nhẹ và không đồng bộ. Mặc dù Gunicorn là đồng bộ, nó hỗ trợ sử dụng các loại worker không đồng bộ như Uvicorn, với đó giao tiếp không đồng bộ có thể được thiết lập. Điều này là cần thiết cho các ứng dụng có thời gian chờ lâu hơn. Trong trường hợp tìm nạp phản hồi từ LLM, bạn nên dự đoán thời gian chờ cao hơn.
• FastAPI để phục vụ các yêu cầu thực tế tại lớp ứng dụng cổng AI tạo sinh.
• Amazon ECS Fargate cluster để lưu trữ ứng dụng được container hóa trên AWS, và AWS Auto Scaling để tự động mở rộng hoặc thu nhỏ các tác vụ hoặc container.
• Amazon Elastic Container Registry (Amazon ECR) để lưu trữ hình ảnh Docker của ứng dụng cổng AI tạo sinh.
• Elastic Load Balancing (ELB) và Application Load Balancer để cân bằng tải các yêu cầu trên các container ECS.
• HashiCorp Terraform để cấp phát tài nguyên.

Hình sau minh họa thiết kế kiến trúc của giải pháp được đề xuất. Các ứng dụng tiêu dùng (như ứng dụng kinh doanh tại chỗ, ứng dụng suy luận, ứng dụng Streamlit và Amazon SageMaker Studio Lab), bảng điều khiển và các thành phần Azure Cloud không được bao gồm trong kho lưu trữ GitHub đi kèm. Chúng được bao gồm trong sơ đồ kiến trúc để minh họa sự tích hợp với các hệ thống hạ nguồn và thượng nguồn.

Rào chắn tập trung

Cổng AI tạo sinh thực thi các kiểm soát bảo mật toàn diện thông qua Amazon Bedrock Guardrails, sử dụng API ApplyGuardrail để triển khai nhiều lớp bảo vệ. Các guardrail này cung cấp bốn tính năng an toàn cốt lõi: lọc nội dung để sàng lọc nội dung không phù hợp hoặc có hại, các chủ đề bị từ chối để giúp ngăn chặn các cuộc thảo luận về chủ đề cụ thể, bộ lọc từ để chặn các thuật ngữ hoặc cụm từ cụ thể và phát hiện thông tin nhạy cảm để giúp bảo vệ dữ liệu cá nhân và bí mật.

Các tổ chức có thể triển khai các kiểm soát này bằng ba cấp độ mạnh có thể cấu hình—thấp, trung bình và cao. Bằng cách này, các đơn vị kinh doanh có thể điều chỉnh tư thế bảo mật AI của họ với mức độ chấp nhận rủi ro và yêu cầu tuân thủ cụ thể của họ. Ví dụ, một nhóm tiếp thị có thể hoạt động với các guardrail có độ mạnh thấp để tạo nội dung sáng tạo, trong khi các bộ phận tài chính hoặc chăm sóc sức khỏe có thể yêu cầu các guardrail có độ mạnh cao để xử lý dữ liệu khách hàng nhạy cảm. Ngoài các biện pháp bảo vệ cơ bản này, Amazon Bedrock Guardrails còn bao gồm các tính năng nâng cao như định vị ngữ cảnh (contextual grounding) và kiểm tra suy luận tự động, giúp phát hiện và ngăn chặn các AI hallucinations (các trường hợp mô hình tạo ra thông tin sai lệch hoặc gây hiểu lầm). Người dùng có thể mở rộng các chức năng của cổng AI tạo sinh để hỗ trợ các tính năng nâng cao này dựa trên trường hợp sử dụng của họ.

Tích hợp đa nhà cung cấp

Cổng AI tạo sinh không phụ thuộc vào LLM provider và model, cho phép tích hợp liền mạch với nhiều nhà cung cấp và LLM. Người dùng có thể chỉ định mô hình LLM ưa thích của họ trực tiếp trong payload yêu cầu, cho phép cổng định tuyến các yêu cầu đến điểm cuối mô hình thích hợp. AWS Secrets Manager được sử dụng để lưu trữ các token truy cập API của cổng AI tạo sinh và các token truy cập từ các LLM bên thứ ba như Azure OpenAI. Token API của cổng AI tạo sinh được sử dụng để xác thực người gọi. Token truy cập LLM được sử dụng để thiết lập kết nối client cho các nhà cung cấp bên thứ ba.

Ghi nhật ký, giám sát và cảnh báo

Một lợi thế chính của việc triển khai cổng AI tạo sinh là cách tiếp cận tập trung để ghi nhật ký và giám sát các LLM interactions. Mọi tương tác, bao gồm các yêu cầu và prompt của người dùng, phản hồi của LLM và ngữ cảnh người dùng, đều được ghi lại và lưu trữ ở định dạng và vị trí tiêu chuẩn hóa. Các tổ chức có thể sử dụng chiến lược thu thập này để thực hiện phân tích, khắc phục sự cố và rút ra thông tin chi tiết. Ghi nhật ký, giám sát và cảnh báo được kích hoạt bằng cách sử dụng các dịch vụ AWS sau:

• Amazon CloudWatch thu thập nhật ký container và ứng dụng. Chúng ta có thể tạo các metric tùy chỉnh trên các thông báo nhật ký cụ thể và tạo một cảnh báo có thể được sử dụng để cảnh báo chủ động (ví dụ: khi xảy ra lỗi 500 Internal Server Error)
• Amazon Simple Notification Service (Amazon SNS) để thông báo đến một danh sách phân phối (ví dụ: khi xảy ra lỗi 500 Internal Server Error)
• Kinesis Data Streams và Data Firehose để truyền dữ liệu yêu cầu và phản hồi cũng như siêu dữ liệu đến Amazon S3 (để tuân thủ và phân tích hoặc chargeback). Chargeback là một cơ chế để phân bổ chi phí cho một hệ thống phân cấp các chủ sở hữu. Ví dụ, một ứng dụng chạy trên AWS sẽ phát sinh một số chi phí cho mỗi dịch vụ, tuy nhiên ứng dụng có thể phục vụ một nhân viên làm việc cho một dự án được quản lý bởi một đơn vị kinh doanh. Chargeback là một quy trình mà chi phí có thể được phân bổ đến cấp thấp nhất của một người dùng cá nhân với tiềm năng tổng hợp ở nhiều cấp độ trung gian cho đến đơn vị kinh doanh.
• Amazon S3 để lưu trữ các yêu cầu và phản hồi ở cấp độ giao dịch (để tuân thủ), ngoài siêu dữ liệu giao dịch và các metric (ví dụ: số lượng token) để phân tích và chargeback.
• AWS Glue Crawler API và Amazon Athena để hiển thị một bảng SQL của siêu dữ liệu giao dịch để phân tích và chargeback.

Cấu trúc kho lưu trữ

Kho lưu trữ GitHub chứa các thư mục và tệp sau:

genai-gateway/ 
├── src/ -- Main application code
│   └── clients/ -- API endpoints
│   ├── controllers/ --FastAPI application entry point
│   ├── generators/ --LLM integration
│   ├── persistence/ -- Persistence logic
│   └── utils/
├── terraform/ -- IaC
├── tests/ -- Testing scripts
│   └── regressiontests/
├── .gitignore
├── .env.example
├── Dockerfile
├── ngnix.conf
├── asgi.py
├── docker-entrypoint.sh
├── requirements.txt
├── serve.py
└── README.md

Điều kiện tiên quyết

Bạn cần các điều kiện tiên quyết sau trước khi triển khai giải pháp này:

• Một AWS Account
• Một vai trò AWS Identity and Access Management (IAM) với các quyền sau:
  • Truy cập Amazon S3 (CreateBucket, PutObject, GetObject, DeleteObject)
  • Truy cập AWS Secrets Manager
  • Truy cập nhật ký Amazon CloudWatch
  • Dịch vụ Amazon Bedrock
  • Truy cập Foundation Model (FM) của Amazon Bedrock
  • Quyền IAM của Amazon Bedrock Guardrails
• Quyền IAM cho Amazon Bedrock Guardrails:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "bedrock:ApplyGuardrail",
                "bedrock:ListGuardrails",
                "bedrock:GetGuardrail"
            ],
            "Resource": "arn:aws:bedrock:<AWS_REGION>:<AWS_ACCOUNT_ID>:guardrail/*"
        }
    ]
}

• Quyền truy cập vào các FM không máy chủ trên Amazon Bedrock được tự động kích hoạt. Bạn không cần yêu cầu hoặc kích hoạt quyền truy cập mô hình theo cách thủ công, nhưng bạn có thể sử dụng chính sách IAM và chính sách kiểm soát dịch vụ để hạn chế quyền truy cập mô hình khi cần.
• Các điểm cuối LLM bên ngoài được cấu hình trong môi trường khách hàng. Ví dụ, các điểm cuối Azure OpenAI phải được tạo trong tài khoản Azure của khách hàng với quy ước đặt tên sau: {model_name}-{azure_tier}-{azure_region}. Ví dụ: {gpt-4o}-{dev}-{eastus}.

Triển khai giải pháp

Trong hướng dẫn triển khai được cung cấp trong phần này, chúng tôi giả định rằng các hướng dẫn triển khai bao gồm các bước cho môi trường dev. Các bước tương tự có thể được sử dụng cho các môi trường cao hơn.

Để bảo vệ các ứng dụng AI tạo sinh bằng các guardrail tập trung, hãy làm theo các bước sau:

1. Clone kho lưu trữ GitHub và đảm bảo các biến môi trường để xác thực AWS có sẵn trong môi trường của bạn.
2. Thực thi ./deploy.sh, tự động thiết lập một Terraform state bucket, tạo một chính sách IAM cho Terraform và cấp phát cơ sở hạ tầng với các phụ thuộc.
3. Gọi ./verify.sh để xác minh việc triển khai và đảm bảo môi trường sẵn sàng để thử nghiệm.
4. Làm theo hướng dẫn trong README, Tạo token xác thực cho người tiêu dùng, để tạo token ủy quyền cho người tiêu dùng.
5. Làm theo hướng dẫn trong README, Kiểm tra Gateway, để kiểm tra cổng AI tạo sinh của riêng bạn.

Để phát triển và thử nghiệm, toàn bộ thiết lập có thể được thực hiện trên máy tính xách tay của nhà phát triển với máy chủ cổng AI tạo sinh và client chạy trên máy tính xách tay của người dùng bằng cách làm theo hướng dẫn thiết lập cục bộ trong README.

Ví dụ

Trong ví dụ đầu tiên này, đoạn mã sau là một lệnh curl để gọi mô hình anthropic.claude-3-sonnet-20240229-v1:0 với guardrail có độ mạnh cao để minh họa cách các guardrail của cổng AI tạo sinh hoạt động chống lại các chủ đề bị từ chối. Ví dụ đầu tiên minh họa hiệu quả của cơ chế an toàn trong việc chặn các chủ đề bị từ chối bằng cách hỏi mô hình, Tôi muốn bán nhà và đầu tư số tiền thu được vào một cổ phiếu duy nhất. Tôi nên mua cổ phiếu nào?:

#!/bin/bash
# Default Configuration (can be overridden by environment variables)
URL=${URL:-"https://<your-alb-dns-name>/process"}
APPID=${APPID:-"admin"}
APITOKEN=${APITOKEN:-"<your-api-token>"}
MODEL=${MODEL:-"anthropic.claude-3-sonnet-20240229-v1:0"}
USER_PROMPT=${USER_PROMPT:-"I want to sell my house and invest the proceeds in a single stock. Which stock should I buy?"}
SYSTEM_PROMPT=${SYSTEM_PROMPT:-" You are an expert financial advisor"}
GUARDRAIL_STRENGTH=${GUARDRAIL_STRENGTH:-"high"}
ENABLE_GUARDRAIL=${ENABLE_GUARDRAIL:-"true"}
USERID=${USERID:-"skoppar"}
COSTCENTER=${COSTCENTER:-"ags"}
MAX_TOKENS=${MAX_TOKENS:-20}
REQUEST_ID=$(uuidgen | tr '[:upper:]' '[:lower:]' | tr -d '-')
REQUEST_DATETIME=$(date -u +"%Y-%m-%dT%H:%M:%S%z")
# Bedrock request payload
echo "Sending request to $URL..."
curl -k -X POST "$URL" \
  -H "Content-Type: application/json" \
  -H "appid: $APPID" \
  -H "apitoken: $APITOKEN" \
  -w "\nHTTP Status: %{http_code}\n" \
  -d @- << EOF
{
  "requestid": "$REQUEST_ID",
  "requestdatetime": "$REQUEST_DATETIME",
  "appid": "$APPID",
  "userid": "$USERID",
  "costcenter": "$COSTCENTER",
  "provider": "amazon-bedrock",
  "apicontext": "chatcompletions",
  "requestbody": {
    "model": "$MODEL",
    "body": {
      "anthropic_version": "bedrock-2023-05-31",
      "max_tokens": $MAX_TOKENS,
      "system": "$SYSTEM_PROMPT",
      "messages": [
        {
          "role": "user",
          "content": "$USER_PROMPT"
        }
      ]
    },
    "accept": "application/json",
    "contentType": "application/json"
  },
  "guardrail_strength": "$GUARDRAIL_STRENGTH",
  "enable_guardrail": $ENABLE_GUARDRAIL
}
EOF

Đoạn mã mẫu sau là đầu ra từ lệnh curl trước đó. Kết quả này bao gồm văn bản được tạo bởi mô hình và các sửa đổi hoặc can thiệp được áp dụng bởi các guardrail có độ mạnh cao. Phân tích đầu ra này giúp xác minh hiệu quả của các guardrail và đảm bảo rằng phản hồi của mô hình phù hợp với các thông số an toàn và tuân thủ đã chỉ định:

{
   "transactionid":"ff73cd3c-b924-40b3-85d7-bcd36cf26ab6",
   "dt":"20251027",
   "transactionstartdate":"2025-10-27 15:51:48+0000",
   "requestid":"6b274e0ad6ad447a90d33e882687767f",
   "requestdatetime":"2025-10-27T15:51:47+0000",
   "appid":"admin",
   "provider":"amazon-bedrock",
   "costcenter":"ags",
   "userid":"skoppar",
   "promptlength":125,
   "guardrail_id":[
      "arn:aws:bedrock:us-east-1: <account-id>:guardrail/o9mj8miraler"
   ],
   "guardrail_action":[
      "topicPolicy"
   ],
   "enable_guardrail":true,
   "responsebody":"{\"usage\": {\"topicPolicyUnits\": 1, \"contentPolicyUnits\": 1, \"wordPolicyUnits\": 1, \"sensitiveInformationPolicyUnits\": 1, \"sensitiveInformationPolicyFreeUnits\": 1, \"contextualGroundingPolicyUnits\": 0}, \"action\": \"GUARDRAIL_INTERVENED\", \"outputs\": [{\"text\": \"Sorry, the content doesn't comply with Responsible AI policies so it cannot be processed!\"}], \"assessments\": [{\"topicPolicy\": {\"topics\": [{\"name\": \"investment_topic\", \"type\": \"DENY\", \"action\": \"BLOCKED\"}]}}]}"
}

Ví dụ thứ hai kiểm tra khả năng của cổng AI tạo sinh trong việc giúp bảo vệ thông tin cá nhân nhạy cảm. Nó mô phỏng một truy vấn người dùng chứa thông tin nhận dạng cá nhân (PII) như tên, số An sinh xã hội và địa chỉ email.

USER_PROMPT="My name is John Smith, my SSN is 123-45-6789, and my email is john.smith@email.com. Can you help me with my account?" ./bedrock_curl_test.sh

Trong trường hợp này, guardrail đã can thiệp thành công và che giấu dữ liệu PII trước khi gửi truy vấn người dùng đến LLM, bằng chứng là trường guardrail_action, cho thấy sensitiveInformationPolicy đã được áp dụng:

{
  "transactionid": "47665380-bf9f-4ed2-836e-916199a45518",
  "dt": "20250626",
  "transactionstartdate": "2025-06-26 23:02:59+0000",
  "requestid": "ebaf1fbffcd344f3b3d96353e772205d",
  "requestdatetime": "2025-06-26T23:02:59+0000",
  "appid": "admin",
  "provider": "amazon-bedrock",
  "costcenter": "proserve",
  "userid": "bommi",
  "promptlength": 149,
  "guardrail_id": [
    "arn:aws:bedrock:us-east-1:<account-id>:guardrail/jvf0bhhvtyf7",
    "arn:aws:bedrock:us-east-1:<account-id>:guardrail/uekx7u8xra91"
  ],
  "guardrail_action": ["sensitiveInformationPolicy"],
  "enable_guardrail": true,
  "responsebody": {
    "id": "msg_bdrk_012UbTrdpzy3iZ2s9wcKF6PU",
    "type": "message",
    "role": "assistant",
    "model": "claude-3-sonnet-20240229",
    "content": [
      {
        "type": "text",
        "text": "I'm afraid I cannot provide any personal information or account details. For privacy reasons, I do not"
      }
    ],
    "stop_reason": "max_tokens",
    "stop_sequence": null,
    "usage": { "input_tokens": 57, "output_tokens": 20 }
  }
}

Để có các tập lệnh kiểm tra toàn diện hơn, vui lòng tham khảo thư mục /test của kho lưu trữ. Các tập lệnh bổ sung này cung cấp một loạt các trường hợp và kịch bản kiểm tra rộng hơn để đánh giá kỹ lưỡng chức năng và hiệu suất của cổng AI tạo sinh.

Dọn dẹp

Sau khi hoàn tất việc khám phá giải pháp này, bạn có thể dọn dẹp các tài nguyên bằng cách làm theo các bước sau:

1. Sử dụng terraform destroy để xóa các tài nguyên được cấp phát bởi Terraform.
2. (Tùy chọn) Từ AWS Management Console hoặc AWS Command Line Interface (AWS CLI), xóa các tài nguyên không bị xóa bởi Terraform (chẳng hạn như S3 bucket, ECR repository và EC2 subnet).

Ước tính chi phí

Phần này mô tả cấu trúc chi phí cơ bản để chạy giải pháp. Khi triển khai giải pháp này, có một số loại chi phí cần được xem xét:

1. Chi phí nhà cung cấp LLM – Đây là các khoản phí cho việc sử dụng các Foundation Model thông qua các nhà cung cấp khác nhau, bao gồm các mô hình được lưu trữ trên Amazon Bedrock và các nhà cung cấp bên thứ ba. Chi phí thường được tính dựa trên:
   • Số lượng token đầu vào và đầu ra được xử lý
   • Độ phức tạp và khả năng của mô hình
   • Khối lượng và mẫu sử dụng
   • Yêu cầu mức dịch vụ
2. Chi phí cơ sở hạ tầng AWS – Đây bao gồm các chi phí cơ sở hạ tầng liên quan đến cổng AI tạo sinh:
   • Tài nguyên tính toán (Amazon ECS Fargate)
   • Cân bằng tải (Application Load Balancer)
   • Lưu trữ (Amazon S3, Amazon ECR)
   • Giám sát (Amazon CloudWatch)
   • Xử lý dữ liệu (Amazon Kinesis)
   • Dịch vụ bảo mật (AWS Secrets Manager)
3. Chi phí Amazon Bedrock Guardrails – Đây là các khoản phí cụ thể để triển khai các tính năng an toàn và tuân thủ:
   • Lọc và kiểm duyệt nội dung
   • Thực thi chính sách
   • Bảo vệ dữ liệu nhạy cảm

Các bảng sau cung cấp một ví dụ về phân tích chi phí để triển khai và sử dụng cổng AI tạo sinh. Để biết giá thực tế, hãy tham khảo AWS Pricing Calculator.

Chi phí cơ sở hạ tầng:

Chi phí LLM và guardrails:

Chi phí LLM có thể thay đổi đáng kể dựa trên số lượng cuộc gọi API, độ dài token đầu vào/đầu ra, lựa chọn mô hình và chiết khấu theo khối lượng. Chúng tôi xem xét một kịch bản sử dụng vừa phải khoảng 50–200 truy vấn mỗi ngày, với độ dài đầu vào trung bình 500 token và độ dài đầu ra trung bình 250 token. Các chi phí này có thể tăng đáng kể với khối lượng truy vấn cao hơn, các cuộc hội thoại dài hơn, sử dụng các mô hình đắt tiền hơn và nhiều cuộc gọi mô hình cho mỗi yêu cầu.

Kết luận

Giải pháp cổng AI tạo sinh đa nhà cung cấp tùy chỉnh với các guardrail tập trung cung cấp một cách tiếp cận mạnh mẽ và có khả năng mở rộng để các doanh nghiệp sử dụng LLM một cách an toàn trong khi vẫn duy trì các tiêu chuẩn bảo mật và tuân thủ. Thông qua việc triển khai API ApplyGuardrail của Amazon Bedrock Guardrails, giải pháp cung cấp việc thực thi chính sách nhất quán về an toàn prompt và bảo vệ dữ liệu nhạy cảm trên cả Amazon Bedrock và các nhà cung cấp LLM bên thứ ba.

Các lợi thế chính của giải pháp này bao gồm:

• Các guardrail tập trung với các cấp độ bảo mật có thể cấu hình
• Khả năng tích hợp LLM đa nhà cung cấp
• Các tính năng ghi nhật ký và giám sát toàn diện
• Khả năng mở rộng cấp độ sản xuất thông qua container hóa
• Khả năng tuân thủ và kiểm toán tích hợp

Các tổ chức, đặc biệt là những tổ chức trong các ngành được quản lý chặt chẽ, có thể sử dụng kiến trúc này để áp dụng và mở rộng các triển khai AI tạo sinh của họ trong khi vẫn duy trì quyền kiểm soát đối với việc bảo vệ dữ liệu và các quy định an toàn AI. Thiết kế linh hoạt và cơ sở hạ tầng mạnh mẽ của giải pháp làm cho nó trở thành một công cụ có giá trị cho các doanh nghiệp muốn khai thác sức mạnh của AI tạo sinh một cách an toàn trong khi quản lý các rủi ro liên quan.

Về tác giả

Hasan Shojaei Tiến sĩ, là Nhà khoa học dữ liệu cấp cao tại AWS Professional Services, nơi ông giúp khách hàng trong các ngành khác nhau như thể thao, dịch vụ tài chính và sản xuất giải quyết các thách thức kinh doanh bằng cách sử dụng các công nghệ AI/ML tiên tiến. Ngoài công việc, Hasan có niềm đam mê với sách, nhiếp ảnh và trượt tuyết.

Sunita Koppar là Kiến trúc sư giải pháp chuyên gia cấp cao về AI tạo sinh và Machine Learning tại AWS, nơi cô hợp tác với khách hàng trong nhiều ngành khác nhau để thiết kế giải pháp, xây dựng các bằng chứng khái niệm và thúc đẩy kết quả kinh doanh có thể đo lường được. Ngoài vai trò chuyên môn, cô còn có niềm đam mê sâu sắc với việc học và dạy tiếng Phạn, tích cực tham gia vào các cộng đồng sinh viên để giúp họ nâng cao kỹ năng và phát triển.

Anuja Narwadkar là Giám đốc quản lý tương tác cấp cao toàn cầu tại AWS Professional Services, chuyên về các chuyển đổi Machine Learning và GenAI quy mô doanh nghiệp. Cô dẫn dắt các nhóm ProServe trong việc xây dựng chiến lược, kiến trúc và phát triển các giải pháp AI/ML mang tính chuyển đổi trên AWS cho các doanh nghiệp lớn trong nhiều ngành, bao gồm cả dịch vụ tài chính. Ngoài vai trò chuyên môn, cô còn thích thúc đẩy các sáng kiến nâng cao kỹ năng AI, đặc biệt cho phụ nữ, đọc sách và nấu ăn.

Krishnan Gopalakrishnan là Tư vấn viên triển khai tại AWS Professional Services với hơn 12 năm kinh nghiệm trong Kiến trúc dữ liệu doanh nghiệp và Kỹ thuật AI/ML. Ông kiến trúc các giải pháp dữ liệu tiên tiến cho các công ty Fortune 500, xây dựng các đường ống quan trọng và triển khai AI tạo sinh trong các lĩnh vực bán lẻ, chăm sóc sức khỏe, fintech và sản xuất. Krishnan chuyên về các kiến trúc đám mây gốc, có khả năng mở rộng, biến dữ liệu doanh nghiệp thành thông tin chi tiết dựa trên AI có thể hành động, cho phép đạt được kết quả kinh doanh có thể đo lường được thông qua việc ra quyết định dựa trên dữ liệu.

Bommi Shin là Tư vấn viên triển khai tại AWS Professional Services, nơi cô giúp khách hàng doanh nghiệp triển khai các giải pháp trí tuệ nhân tạo an toàn, có khả năng mở rộng bằng cách sử dụng công nghệ đám mây. Cô chuyên thiết kế và xây dựng các nền tảng AI/ML và AI tạo sinh nhằm giải quyết các thách thức kinh doanh phức tạp trong nhiều ngành. Ngoài công việc, cô thích đi du lịch, khám phá thiên nhiên và thưởng thức các món ăn ngon.