Đang chạy mực qua máy in — từng lớp màu một, kiên nhẫn nhé!
№ 01
№ 02
№ 03
№ 04
№ 05
№ 06
AirFuture · AI·20K Demo Day Zine
№ 48
AirFuture
AirFuture là AI agent giám sát và dự báo chất lượng không khí đô thị theo thời gian thực: cảm biến báo, luật cứng chấm mức nguy hiểm, AI giải thích và đề xuất, con người bấm duyệt trước khi hành động.
Fig. 01 · Ảnh dự án
AirFuture
AI agent giám sát và dự báo chất lượng không khí đô thị theo thời gian thực — cảm biến báo, luật cứng chấm mức nguy hiểm, AI giải thích và đề xuất, con người bấm duyệt trước khi hành động.
Đề tài SC-07 · VinUni AI20K Build Phase, Cohort 3 · Nhóm Anyways
Phạm Đức Thiện (Nhóm trưởng — LSTM, Eval & CI/CD) · Nguyễn Minh Quang (Backend, API, Frontend) · Đoàn Văn Tuyền (Frontend, mô phỏng IoT) · Võ Quốc Huy (AI Agents, Guardrails, Zalo)
1. Bài toán
Số liệu môi trường trong các khu dân cư/toà nhà không hề thiếu — cảm biến IoT đo liên tục. Cái thiếu là khả năng đọc kịp và hiểu đúng số liệu đó, ở đúng ba nhóm người cần nó:
Đối tượng
Vấn đề cụ thể
Ban Quản Lý (BQL) toà nhà
Nhân lực mỏng — một người trực, hàng chục cảm biến, nhiều màn hình rời rạc. Bất thường chỉ lộ ra khi đã bùng phát, cảnh báo tới trễ.
Cư dân
Chỉ số thô, phải tự đoán lấy ý nghĩa. "PM2.5 = 86" không nói cho một phụ huynh biết có nên cho trẻ ra ngoài hay không.
Ứng dụng chất lượng không khí hiện có
Dừng lại ở hiển thị tức thời — không dự báo trước xu hướng, không cá nhân hoá theo tình trạng sức khoẻ hộ gia đình, và không chạm được tới thiết bị vật lý (quạt thông gió...) để thực sự xử lý sự cố.
Nói ngắn gọn: có dữ liệu, không có hành động. Khoảng trống nằm giữa "cảm biến đo được gì" và "con người nên làm gì tiếp theo".
2. Giải pháp kỹ thuật
2.1 Nguyên lý cốt lõi: deterministic trước, LLM sau, con người chốt cuối
AirFuture không để AI tự quyết định điều gì là nguy hiểm. Toàn hệ thống vận hành theo một vòng khép kín, một điểm chốt duy nhất là con người:
Cảm biến → Luật cứng đánh giá rủi ro → AI giải thích & đề xuất → Người phê duyệt → Thiết bị chạy → Cư dân được báo
Ba nguyên tắc bất biến chi phối toàn bộ kiến trúc:
AI không bao giờ tự quyết định mức độ nguy hiểm. Mức rủi ro (LOW/MODERATE/HIGH/CRITICAL/SEVERE) do công thức Python (risk_engine) tính bằng cách so ngưỡng với cửa sổ trượt chuẩn (24h cho PM2.5/PM10, 8h cho CO/O3, 1h cho nhiệt độ/độ ẩm) — tái lập được, kiểm toán được, và vẫn chạy đúng ngay cả khi mất kết nối LLM. LLM chỉ giải thích nguyên nhân và dựa trên mức rủi ro đã tính sẵn, và mọi output của nó đều bị validate lại bằng schema Pydantic + kiểm tra tham chiếu thực tế trước khi ghi vào cơ sở dữ liệu.
§
Phụ lục — Demo & Slides
Video demo
Bản demo trực tiếp
Slide trình bày
đề xuất hành động
AI không bao giờ tự điều khiển thiết bị vật lý. Mọi lệnh điều khiển quạt thông gió sinh ra đều ở trạng thái PENDING_APPROVAL. Chỉ vai trò Ban Quản Lý/Admin mới được duyệt hoặc từ chối — đây là ràng buộc Human-in-the-loop được cưỡng chế ở tầng backend và tầng Policy Gate, không phải chỉ hiển thị trên giao diện.
Ranh giới y tế nghiêm ngặt. Hệ thống không chẩn đoán bệnh, không kê đơn, không suy đoán nguyên nhân y khoa. Dữ liệu hộ gia đình chỉ là "Nhãn độ nhạy cảm môi trường" dùng để hiệu chỉnh ngưỡng cảnh báo — ranh giới này được cưỡng chế ở ba lớp: system prompt, guardrail chuyên biệt, và bộ eval đối kháng với ngưỡng chặn cứng 100%.
2.2 Ba bề mặt, ba nhóm người dùng
Không phải một app cho tất cả — mỗi nhóm người dùng có một kênh riêng phù hợp với nhu cầu:
Bề mặt
Đối tượng
Chức năng chính
Dashboard Next.js (15 trang)
Ban Quản Lý
Bản đồ nhiệt theo khu vực, chi tiết cảnh báo kèm phân tích AI, nút duyệt/từ chối lệnh điều khiển, báo cáo xuất PDF/CSV, quản trị master data
Chat Zalo 1-1
Cư dân
Hỏi đáp tiếng Việt về AQI/thời tiết, khai báo độ nhạy cảm môi trường hộ gia đình, kết nối Google Calendar, bản tin chủ động mỗi sáng 6 giờ
Màn hình công cộng
Người qua đường
LED sảnh & TV thang máy hiển thị AQI/khuyến cáo, không cần đăng nhập, tự báo khi mất kết nối
2.3 Kiến trúc hệ thống
Cảm biến IoT / Node-RED ─┐
├─ MQTT (HiveMQ Cloud, TLS)
OpenWeather API ──────────┘
│
▼
FastAPI Backend
├─ MQTT Consumer (auto-provision zone/device, ghi sensor_reading)
├─ Assessment Worker — tính cửa sổ trượt + VN-AQI (QĐ 1459/QĐ-TCMT)
├─ Risk Engine — luật cứng, KHÔNG LLM
├─ Incident Agent (LangGraph, 13 node) — chỉ 3 node gọi LLM
├─ LSTM Predictor — dự báo PM2.5/PM10/CO2 1–6 giờ tới
├─ Guardrails 5 lớp + Policy Gate 8 chặng — kiểm soát mọi lệnh gọi công cụ AI
└─ REST/WebSocket API (92 endpoint)
│
▼
TimescaleDB (Postgres, 59 bảng) ── HuggingFace model registry (LSTM)
│
▼
Dashboard Next.js · Zalo bridge (Node.js, zca-js) · Màn hình công cộng
Vì sao LangGraph: máy trạng thái tường minh (state machine), không phải vòng lặp agent tự do — mỗi bước là một hàm Python thuần, kiểm soát và kiểm toán được từng node, dễ test độc lập.
Vì sao TimescaleDB: mở rộng từ Postgres, tối ưu sẵn cho dữ liệu chuỗi thời gian — đúng hình dạng của dữ liệu cảm biến đo liên tục.
2.4 Incident Agent — 13 node, chỉ 3 node gọi LLM
Đây là bộ não xử lý sự cố, kích hoạt tự động mỗi khi có Alert mới:
Chuỗi tất định, không LLM: initialize_run → validate_alert → load_context → check_data_quality → assess_risk (luật cứng). Rủi ro LOW dừng ở đây — chỉ lưu kết quả, không sinh cảnh báo/thông báo, không tốn chi phí gọi LLM.
Từ mức trung bình trở lên, 3 node có LLM: analyze_context (phân tích nguyên nhân + đánh giá sức khoẻ theo từng nhóm cư dân) → generate_actions (đề xuất hành động, có validate lại thiết bị/nhóm cư dân tồn tại thật) → compose_notifications (soạn nội dung thông báo).
Mọi lần chạy đều idempotent (ràng buộc unique ở tầng database, không chỉ ở code) và được ghi audit log đầy đủ.
Nếu thiếu API key hoặc LLM lỗi, hệ thống rơi vào nhánh fallback tất định — không bao giờ bịa nội dung giả khi không có dữ liệu trong tay.
2.5 An toàn nhiều lớp
Ba lớp phòng thủ độc lập, xếp chồng — một lớp bị vượt qua thì lớp sau vẫn chặn:
Guardrails 5 lớp: chuẩn hoá input, lọc chữ ký độc hại nhanh, phân loại an toàn ngữ nghĩa (chống prompt injection), Tool Policy Gate, và redaction/kiểm tra ranh giới y tế ở output.
Policy Gate 8 chặng cho mọi lệnh gọi công cụ AI: kiểm tra tool tồn tại → phân quyền theo vai trò (fail-closed) → validate schema → kiểm quyền theo tài nguyên → phân loại tác dụng phụ → cưỡng chế xác nhận/Human-in-the-loop → chống replay → thực thi có timeout + audit.
Tầng neo dữ liệu: mọi khẳng định của AI phải khớp với số đo thật hệ thống ghi nhận — không được "trấn an" khi không có bằng chứng (xem mục Thách thức & Bài học).
3. Tính khả thi
3.1 Quy mô thật, không phải bản demo
Chỉ số
Giá trị
Dòng code Python backend
30.070
Hàm test
1.012 (trải trên 110 tệp)
Test coverage
71%
Endpoint REST & WebSocket
92
Bảng TimescaleDB
59
Công cụ AI có kiểm soát quyền
14
3.2 Kết quả đánh giá (eval) đo được
Hạng mục
Kết quả
Chat — an toàn nội dung
5/5
Điểm liên quan câu trả lời
4,85 / 5
Bất biến duyệt công cụ phần cứng (Human-in-the-loop)
1,00 (100%)
Hạng mục eval bắt buộc đạt
100% (11/11)
Ràng buộc hiệu năng: một lượt chat tối đa 45 giây, tối đa 8 lần gọi công cụ — có ngân sách cứng để tránh vòng lặp agent vô hạn.
3.3 Vận hành & CI/CD đã kiểm chứng
Mọi push/PR: chạy ruff (lint) + pytest (test suite) + gate rủi ro + build Admin UI tự động qua GitHub Actions.
Job riêng phát hiện lệch schema: kiểm tra migration khớp với mô hình dữ liệu — đúng lớp lỗi từng khiến agent chỉ chạy thành công 2/33 lần trong giai đoạn phát triển sớm, nay đã được chặn ở CI trước khi merge.
Merge vào main: tự động build Docker image và SSH deploy lên Oracle Cloud; frontend deploy qua Vercel.
3.4 Đã hoàn thiện và chạy được thật (không chỉ trên giấy)
Toàn chuỗi Sensor → DB → LSTM → Agent → Alert → Notification chạy nối thông đầu-cuối, xác minh bằng test thật, không phải các module rời rạc.
Database 59 bảng, có unique constraint chống ghi trùng kết quả agent, index tối ưu cho time-series, dữ liệu liên hệ được mã hoá.
RBAC rõ ràng bằng JWT: endpoint ghi dữ liệu master yêu cầu ADMIN; nghiệp vụ alert/duyệt lệnh yêu cầu BOARD_MEMBER/ADMIN.
Cập nhật real-time qua WebSocket cho dashboard, có cơ chế polling dự phòng nếu WebSocket rớt kết nối — không có rủi ro hồi quy.
Module chatbot Zalo có vòng đời đầy đủ: dedup hai lớp, retry gửi lỗi, trang quản trị riêng, cá nhân hoá theo hồ sơ hộ gia đình mà không lộ thông tin nhạy cảm.
4. Hướng phát triển
4.1 Ba hướng ưu tiên ngay sau Demo Day
Hiệu chuẩn bộ chấm tự động (eval) — tinh chỉnh bộ tiêu chí và ngưỡng chấm điểm để kết quả eval phản ánh sát hơn chất lượng thực tế của agent, giảm sai số giữa điểm tự động và đánh giá con người.
Chống tiêm lệnh gián tiếp (indirect prompt injection) — củng cố thêm lớp phòng thủ khi dữ liệu không tin cậy (ví dụ nội dung do bên thứ ba cung cấp qua tool output) có thể chứa chỉ thị ẩn nhắm vào agent.
Huấn luyện mô hình LSTM trên dữ liệu thật — hiện mô hình dự báo được huấn luyện chủ yếu trên dữ liệu mô phỏng; chuyển sang dữ liệu cảm biến thật thu thập liên tục sẽ cải thiện độ chính xác dự báo trong điều kiện vận hành thực tế.
4.2 Các hạng mục kỹ thuật cần hoàn thiện
Ưu tiên
Hạng mục
Cao
Hoàn thiện bước gửi lệnh MQTT thật xuống thiết bị thông gió sau khi BQL duyệt — hiện bước duyệt mới dừng ở ghi nhận trạng thái, chưa publish lệnh điều khiển thật ra broker.
Trung bình
Chuyển checkpointer của LangGraph từ lưu tạm sang PostgreSQL bền vững ngay từ đầu (rút kinh nghiệm từ giai đoạn build hiện tại, tránh phải nâng cấp giữa chừng).
Trung bình
Ổn định hoá phiên đăng nhập Zalo bridge — thư viện zca-js hiện chưa lưu session bền vững qua các lần khởi động lại container.
Thấp
Bổ sung Alembic migration thật thay cho create_all() + script vá tay, để có đường rollback an toàn khi lên production chính thức.
4.3 Mở rộng sản phẩm
Mở rộng cá nhân hoá hồ sơ hộ gia đình sang chat nhóm Zalo và giao diện web (hiện chỉ áp dụng cho chat 1-1).
Bổ sung kênh nhận thông báo khác ngoài Zalo cho cư dân không dùng ứng dụng này.
Nhân rộng mô hình từ một toà nhà/khu dân cư sang quản lý nhiều toà nhà/nhiều khu vực đồng thời, tận dụng kiến trúc multi-tenant đã có sẵn ở tầng Policy Gate.
