Điểm khiến bài toán khắt khe hơn nữa: ràng buộc số 2 là ràng buộc an toàn vật lý. Vi phạm một lần là mất điện cả hầm xe. Nó không được phép sai kể cả trong trường hợp hiếm, và vì thế không thể giao cho một mô hình ngôn ngữ quyết định.

2. Giải pháp kỹ thuật

2.1 Nguyên tắc thiết kế cốt lõi

LLM cầm micro, không cầm cầu dao.

Hệ thống tách đôi trách nhiệm một cách dứt khoát:

• Mô hình ngôn ngữ chỉ làm phần giao tiếp — hiểu câu tiếng Việt tự nhiên của cư dân và trích xuất ý định có cấu trúc (ParsedChargingIntent: mức pin hiện tại, mức mong muốn, thời hạn). Nó không có quyền gọi bất kỳ lệnh điều khiển công suất nào.
• Bộ tối ưu tất định (thuần Python, không phụ thuộc LLM) mới là nơi ra mọi quyết định về điện.

Nhờ vậy, an toàn điện của toà nhà không phụ thuộc vào việc mô hình hôm nay có ảo giác hay không.

2.2 Luồng xử lý — LangGraph state machine

Agent được dựng bằng LangGraph, mỗi bước là một node tường minh và có thể kiểm thử độc lập:

input_guardrail → classify_intent
                    ├── out-of-scope ──────→ fallback_out_of_scope
                    ├── hỏi đáp ───────────→ run_qna_tools_and_synthesize
                    └── yêu cầu sạc
                          ↓
                    parse_intent_with_gpt          ← LLM dừng ở đây
                          ↓
                    validate_identity_and_ownership
                          ↓
                    calculate_feasibility → ask_clarification / explain_alternatives
                          ↓
                    await_confirmation             ← cổng xác nhận 2 bước
                          ↓
                    create_request → allocate_or_queue
                          ↓
                    run_optimizer                  ← thuật toán tất định
                          ↓
                    validate_schedule              ← SafetyValidator
                          ↓
                    create_approval (nếu bất lợi)  ← chốt chặn HITL
                          ↓
                    persist_and_dispatch → explain_result_with_gpt

Hai chốt chặn đáng chú ý:

• await_confirmation — agent tóm tắt lại yêu cầu nó đã hiểu và dừng lại. Không có lịch nào được tạo cho tới khi cư dân xác nhận rõ ràng.
• explain_result_with_gpt — LLM chỉ quay lại ở bước cuối để diễn giải kết quả, sau khi mọi quyết định đã được chốt.

2.3 Bộ tối ưu

SmartChargingOptimizer (src/optimizer/optimizer.py) — bộ phân bổ khung giờ tất định, ưu tiên theo thời hạn:

• Chia trục thời gian thành khung 15 phút (cấu hình qua slot_minutes).
• Với mỗi khung, cân nhắc giá điện, phụ tải nền của toà nhà và công suất còn trống dưới trần.
• Sắp thứ tự xe theo độ khẩn (slack = thời gian còn lại so với năng lượng còn thiếu); xe có cùng slack thì xe có deadline sớm hơn được ưu tiên.
• Toàn bộ số học dùng Decimal, không dùng số thực dấu phẩy động — để kết quả tái lập được và kiểm toán được.

Ngoài ra hệ thống tính thêm chỉ số bất mãn người dùng (dissatisfaction.py, theo mô hình Ko et al.). Đây là chỉ số báo cáo, tính sau khi kế hoạch đã hình thành — nó không tham gia vào việc chọn khung giờ, nên không làm mờ tính tất định của bộ tối ưu.

2.4 SafetyValidator — lớp kiểm chứng độc lập

Đây là chi tiết kỹ thuật quan trọng nhất của dự án. SafetyValidator (src/optimizer/safety.py) chạy sau bộ tối ưu và:

tái suy diễn lại toàn bộ bất biến từ đầu ra thô, không tin vào sổ sách nội bộ của bộ tối ưu.

Nghĩa là nó cộng lại tổng công suất từng khung từ chính danh sách slot được sinh ra, so với trần và phụ tải nền, kiểm tra lại từng deadline, từng phép tính năng lượng. Nếu phát hiện vi phạm, nó ném SafetyViolationError và kế hoạch bị chặn — không được phát lệnh xuống trụ.

Cách làm này bảo vệ hệ thống ngay cả khi bộ tối ưu có lỗi logic: một bug trong optimizer không thể biến thành sự cố điện. Có test chuyên biệt bơm đầu ra giả mạo vào validator để chứng minh nó bắt được (test_catches_fabricated_output_that_exceeds_site_limit).

2.5 Human-in-the-loop

Mọi thay đổi bất lợi cho xe đang sạc (giảm công suất, lùi thời gian hoàn tất) không được áp dụng tự động:

• Đề xuất bị treo thành một ApprovalRequest.
• Kế hoạch cũ vẫn tiếp tục chạy trong lúc chờ — hệ thống không rơi vào trạng thái lấp lửng.
• Cư dân hoặc vận hành duyệt/từ chối; quá hạn thì đề xuất tự huỷ.
• Mọi lần điều chỉnh đều ghi vào nhật ký kiểm toán: ai duyệt, lúc nào, vì sao.

Cơ chế move-and-park (cư dân tự nguyện đăng ký khung giờ sẵn sàng nhường trụ) dùng lại đúng đường ống ApprovalRequest này — không tạo luồng phê duyệt song song.

2.6 Kiến trúc & công nghệ

2.7 Chức năng chính, ánh xạ theo nỗi đau

3. Tính khả thi

3.1 Đã chạy được thật, không dừng ở ý tưởng

Toàn bộ hệ thống đã được xây dựng và vận hành end-to-end. Các con số dưới đây đo trực tiếp trên mã nguồn:

3.2 Tính đúng đắn được chứng minh, không chỉ được tuyên bố

Đây là điểm mạnh nhất về mặt khả thi kỹ thuật. Các bất biến an toàn không được kiểm bằng vài test ví dụ, mà bằng property-based testing (Hypothesis) — công cụ tự sinh hàng nghìn kịch bản đầu vào ngẫu nhiên và tìm phản ví dụ:

• test_property_output_never_exceeds_site_limit — đầu ra chưa bao giờ vượt trần công suất.
• test_catches_slot_scheduled_after_deadline — không khung nào bị xếp quá thời hạn.
• test_invariant_planned_energy_math_is_consistent — phép tính năng lượng nhất quán.
• test_catches_fabricated_output_that_exceeds_site_limit — validator bắt được cả đầu ra giả mạo.
• test_adverse_reoptimization_creates_approval_and_keeps_old_plan — HITL giữ đúng kế hoạch cũ trong lúc chờ duyệt.

3.3 Đã kiểm chứng bằng cách chạy thật

Trước khi bàn giao, từng mục dưới đây được chạy thực tế, không phải suy luận trên giấy:

• Chạy từ bản clone sạch: alembic upgrade head → seed → khởi động, lặp lại nhiều lần từ trạng thái trắng.
• docker compose up --build: backend và frontend đều báo healthy, nginx proxy hoạt động.
• Simulator phát telemetry: đưa trụ online và quan sát measured_power_kw cập nhật trong một chu kỳ (2–5s).
• WebSocket tự kết nối lại theo exponential backoff khi rớt mạng.
• Kịch bản HITL đầy đủ: tăng phụ tải nền → tái tối ưu → thay đổi bất lợi bị treo → cư dân duyệt → kế hoạch mới được phát lệnh.
• Deploy tự động lên VPS qua GitHub Actions + GHCR.

3.4 Suy biến an toàn — hệ thống không chết khi thiếu LLM

Một yếu tố khả thi quan trọng cho triển khai thật: hệ thống không phụ thuộc sống còn vào OpenAI. Khi không có API key hoặc key lỗi, endpoint chat trả về 503 LLM_NOT_CONFIGURED một cách có kiểm soát, còn form đặt lịch thủ công vẫn tạo được yêu cầu với đầy đủ chức năng — vì bộ tối ưu và toàn bộ logic điện vốn không cần LLM. Điều này đã được kiểm chứng bằng cách chạy thật với OPENAI_API_KEY rỗng.

3.5 Chi phí triển khai thấp

Hệ thống chạy được trọn vẹn trên một VPS phổ thông với Docker Compose. Không cần cụm máy chủ, không cần GPU, không cần broker MQTT ngoài (có sẵn gateway mô phỏng nội bộ; khi cần thì bật profile Mosquitto). Ban quản lý một toà nhà hoàn toàn có thể tự vận hành.

3.6 Giới hạn hiện tại — nói thẳng

Để đánh giá khả thi cho đúng, cần nêu rõ những gì bản hiện tại chưa làm:

• Trụ sạc là mô phỏng nội bộ, chưa nói chuyện với phần cứng OCPP thật.
• Bộ tối ưu là heuristic tham lam, cho lời giải tốt và an toàn nhưng không chứng minh được là tối ưu toàn cục.
• Mô hình điện là một pha, chưa xét cân bằng ba pha.
• Thanh toán là luồng mô phỏng, chưa nối cổng thanh toán thật.
• Dự báo nhu cầu ở mức heuristic theo thói quen, chưa phải mô hình học máy.

Đây đều là những khoảng cách đã được nhận diện và nằm trong lộ trình dưới đây.

4. Hướng phát triển

4.1 Ngắn hạn (1–3 tháng)

4.2 Trung hạn (3–9 tháng)

4.3 Tham vọng dài hạn

4.4 Vì sao lộ trình này khả thi

MVP đã giải quyết xong phần khó nhất và rủi ro nhất: điều phối công suất an toàn, có kiểm chứng, có con người trong vòng lặp. Các hạng mục phía trên hầu hết là mở rộng quy mô hoặc thay thế một thành phần đã được cô lập sau lớp trừu tượng — chứ không phải viết lại nền móng.

Riêng lớp SafetyValidator giữ nguyên giá trị qua mọi giai đoạn: dù bộ tối ưu có được thay bằng LP, MILP hay mô hình học tăng cường, lớp kiểm chứng độc lập vẫn đứng chắn giữa thuật toán và cầu dao.