API Call Demo — Dashboard

Result IDLE

Chưa có kết quả. Nhập prompt và nhấn Send.

Observability Log 0

Logs sẽ hiển thị ở đây khi có request...

Giới thiệu mục tiêu: Hệ thống gọi API AI Model với đầy đủ cơ chế kiểm soát chất lượng đầu vào/đầu ra.
Trình bày flow trên slide hoặc whiteboard: UI → Input Validation → API Proxy → Model AI → Schema Validation → Response.
Nêu 5 problem statement: Input sai, Output sai cấu trúc, Timeout, Provider down, Không có observability.

💡 Mẹo: Đặt câu hỏi cho người nghe: "Nếu Model trả JSON sai format, hệ thống sẽ xử lý thế nào?" để tạo tương tác.

Bước 1: Nhập Base URL, Model Name, API Key trên sidebar trái.
Bước 2: Chọn sample prompt (🏗️ Infra VN hoặc 🤖 AI News).
Bước 3: Nhấn Send Request → hệ thống gọi Gemini API thật.
Bước 4: Chỉ ra Result panel: structured JSON trả về với summary, entities, sentiment, confidence, language.
Bước 5: Chỉ ra Observability Log: request_id, execution_id, latency_ms, model_name, prompt_version.

💡 Mẹo: Nếu API key chưa có, dùng nút Random Result để giả lập flow thành công trước.

Thử nhập prompt rỗng → nhấn Send → thông báo lỗi ngay lập tức, không gọi API.
Thử nhập prompt quá ngắn (1-2 ký tự) → bị chặn với message "Prompt quá ngắn".
Thử nhập Base URL sai format (không bắt đầu bằng http) → Pydantic validator chặn.
Thử nhập API key rỗng → bị chặn trước khi gửi đi.

💡 Mẹo: Nhấn nút Validate Input (hoặc xem log type: input_validation) để hiện thị chi tiết validation ở log panel.

Nhấn nút Bad Schema → Model trả về {title, score, confidence: 1.5}.
Hệ thống phát hiện: thiếu summary, entities, sentiment, language; confidence vượt [0,1].
Hiển thị schema_errors chi tiết trong Result panel (red error box).
Log ghi nhận status: SCHEMA_ERROR kèm raw_output để debug.

💡 Mẹo: Giải thích: "Hệ thống validate bằng Pydantic + JSON Schema, không phụ thuộc vào prompt mà dùng cấu trúc cứng (hard schema)."

Nhấn Timeout 3s → chờ 3 giây → nhận lỗi REQUEST_TIMEOUT (408). Giải thích: "System tự hủy request, không treo luồng."
Nhấn Timeout 8s → cùng logic nhưng thời gian dài hơn, chứng minh configurable timeout.
Nhấn Provider 503 → nhận lỗi PROVIDER_UNAVAILABLE (503) ngay lập tức.
Nhấn Random Result → chạy nhiều lần sẽ có cả success lẫn schema_error, chứng minh error path.

💡 Mẹo: Chỉ ra log entries: timeout hiện latency màu đỏ (slow), 503 hiện màu cam (warning). Audience thấy real-time observability.

Nhấn nút 📋 → xem Observability Log: mỗi entry có request_id, execution_id, latency_ms, model_name, prompt_version.
Chỉ vào header: Prompt version badge (v1.2.0) được load từ prompts.yaml.
Giải thích: Khi thay đổi prompt_version trong file → reload service → version cập nhật trên UI mà không cần rebuild code.
Clear Logs rồi chạy lại 1 request → show log mới xuất hiện real-time.

💡 Mẹo: Mở file prompts.yaml trên máy tính nếu muốn show cách cấu hình prompt version.

Recap 5 cơ chế chính: End-to-end flow, Input Validation, Schema Validation, Resilience (Timeout/Failure), Observability.
Nêu điểm mạnh: Hệ thống chặn lỗi từ đầu (input), bắt lỗi model trả về (schema), tự phục hồi khi provider sự cố (resilience), và full traceability (observability).
Mở rộng: Có thể tích hợp thêm rate limiting, retry with exponential backoff, multi-model fallback.
Mời Q&A: "Có câu hỏi nào về cách triển khai hoặc mở rộng hệ thống không?"

💡 Mẹo: Nếu hết thời gian, phần 6 (Observability) có thể rút ngắn bằng cách chỉ nói nhanh 1 câu về log.

📋 Kế hoạch trình bày — 20 phút