Một ý tưởng AI thường thất bại không phải vì mô hình yếu, mà vì nhiệm vụ được mô tả quá mơ hồ. “Đọc hồ sơ giúp tôi” không cho biết hồ sơ nào, cần lấy gì, sai kiểu nào là nghiêm trọng, khi nào dừng và ai chịu trách nhiệm.
Muốn triển khai thật, nhiệm vụ phải được chuyển thành một chuỗi có thể quan sát: đầu vào → xử lý → kiểm tra → duyệt → đầu ra → lưu dấu vết.
Chuyên đề: AI ứng dụng trong Bất động sản · Bài 02 · Nền tảng sử dụng AI trong BĐS
Biên soạn: ThS. Nguyễn Mạnh Hùng
GV. Khoa QLĐĐ&BĐS – ĐH Nông Lâm TP.HCM
Email: nguyenmanhhung@hcmuaf.edu.vn
1. Bắt đầu bằng “hợp đồng đầu ra”
Trước khi chọn mô hình, hãy mô tả đầu ra bằng một cấu trúc mà người và máy cùng hiểu. Ví dụ với hồ sơ thuê: mã tài sản, bên thuê, diện tích, ngày bắt đầu, ngày kết thúc, tiền thuê, chu kỳ thanh toán, tiền đặt cọc, quyền gia hạn, điều kiện chấm dứt, trang nguồn và trạng thái xác minh.
Mỗi trường cần biết kiểu dữ liệu, đơn vị, có bắt buộc không và cách biểu diễn thiếu dữ liệu. Khi đầu ra rõ, ta mới xác định dữ liệu đầu vào và cách đánh giá.
2. Mô tả đầu vào theo nguồn và quyền
Không nên ghi đơn giản “đầu vào là PDF”. Một quy trình tốt cần biết tài liệu nào là hợp đồng chính, phụ lục, bản scan, bảng giá, dữ liệu CRM; nguồn nào có thẩm quyền cao hơn; tài liệu nào chứa dữ liệu cá nhân; ai được phép xem.
| Thuộc tính đầu vào | Ví dụ |
|---|---|
| Nguồn | Data room dự án / hệ thống hợp đồng |
| Phiên bản | Hợp đồng ký + phụ lục 02 |
| Thời điểm | Bản nhận ngày 04/10/2026 |
| Quyền | Nhóm pháp lý và quản lý tài sản |
| Chất lượng | PDF có lớp chữ / scan / trang nghiêng |
3. Chia nhiệm vụ thành các bước có trách nhiệm rõ
Ví dụ trích dữ liệu hợp đồng:
- Kiểm kê tài liệu và nhận diện phiên bản.
- Trích nội dung văn bản.
- Nhận diện các điều khoản mục tiêu.
- Xuất dữ liệu theo cấu trúc.
- Kiểm định dạng ngày, tiền, đơn vị.
- Đối chiếu các trường có quan hệ với nhau.
- Gắn bằng chứng trang/đoạn.
- Chuyển ngoại lệ cho người duyệt.
- Sau duyệt mới ghi vào hệ thống quản trị.
AI có thể làm mạnh ở bước 2–4; bước 5–6 nên dùng quy tắc và code; bước 8 là trách nhiệm con người theo ngưỡng rủi ro.
4. Tiêu chí đúng phải đo được
“Kết quả tốt” là chưa đủ. Với bài toán trích xuất, có thể đo độ đúng từng trường, tỷ lệ bỏ sót, tỷ lệ gắn đúng trang nguồn. Với phân loại, có thể đo độ chính xác theo từng lớp và đặc biệt quan tâm lớp rủi ro cao. Với tóm tắt, cần kiểm tính đầy đủ của điểm bắt buộc và tính bám nguồn.
Quan trọng: lỗi không có cùng chi phí. Sai một dấu câu trong mô tả khác hoàn toàn sai ngày hết hạn hợp đồng.
5. Thiết kế điểm kiểm soát
| Điểm kiểm soát | Câu hỏi | Hành động khi không đạt |
|---|---|---|
| Đầu vào | Đúng tài liệu và phiên bản chưa? | Dừng, yêu cầu bổ sung |
| Trích xuất | Trường bắt buộc có bằng chứng không? | Gắn MISSING/UNCLEAR |
| Định dạng | Ngày, tiền, diện tích hợp lệ? | Quy tắc báo lỗi |
| Đối chiếu | Hợp đồng và phụ lục có mâu thuẫn? | Gắn CONFLICT |
| Trước hành động | Người có thẩm quyền đã duyệt? | Không ghi hệ thống |
6. Tách suy luận ngôn ngữ khỏi phép tính
Giả sử hợp đồng quy định tăng tiền thuê 5% mỗi 12 tháng. AI có thể trích “mức tăng 5%, chu kỳ 12 tháng, ngày bắt đầu”. Nhưng bảng tiền thuê từng kỳ nên do code hoặc spreadsheet tính từ các tham số đã duyệt.
Cách tách này giúp tái hiện kết quả, tránh sai số và dễ kiểm toán hơn việc yêu cầu mô hình “tự tính tất cả”.
7. Trạng thái không chắc chắn phải là dữ liệu
Đừng ép hệ thống luôn trả một giá trị. Cho phép bốn trạng thái chuẩn:
- MISSING: nguồn không có dữ liệu cần thiết.
- CONFLICT: các nguồn đưa giá trị mâu thuẫn.
- UNCLEAR: có nội dung nhưng không đủ rõ để kết luận.
- NEEDS_REVIEW: cần chuyên gia quyết định.
Đây là một thiết kế quan trọng để giảm bịa đặt và làm rõ trách nhiệm.
8. Bộ dữ liệu kiểm thử trước khi chạy thật
Nên tạo một bộ tình huống gồm hồ sơ chuẩn, hồ sơ thiếu trang, phụ lục thay đổi điều khoản, bản scan xấu, số tiền viết bằng chữ và số, trường hợp có hai ngày hiệu lực, tài liệu không liên quan. Người có chuyên môn tạo đáp án chuẩn.
Sau mỗi lần đổi mô hình, thay cách chia tài liệu hoặc sửa câu lệnh, chạy lại toàn bộ bộ kiểm thử để xem chất lượng có giảm ở trường hợp cũ không.
9. Xác định vai trò con người
Human-in-the-loop – con người tham gia kiểm soát không có nghĩa mọi kết quả đều phải đọc lại từ đầu. Có thể đặt quy tắc: trường có độ tin cậy thấp, tài liệu mâu thuẫn, giá trị tiền vượt ngưỡng hoặc điều khoản thuộc nhóm quan trọng thì bắt buộc duyệt; trường chuẩn có thể kiểm theo mẫu.
Mức duyệt phải tỷ lệ với hậu quả sai.
10. Nhật ký tối thiểu để tái hiện
Mỗi lần chạy nên có mã công việc, tập tài liệu, thời điểm, phiên bản mô hình, phiên bản câu lệnh, công cụ đã gọi, đầu ra trung gian, cảnh báo, người duyệt và quyết định cuối. Không cần lưu mọi thứ vô hạn; nhưng phải đủ để giải thích một kết quả quan trọng sau này.
11. Khi nào quy trình sẵn sàng đưa vào sử dụng?
Chỉ nên chuyển từ thử nghiệm sang vận hành khi: nguồn dữ liệu ổn định; đầu ra có cấu trúc; bộ kiểm thử đạt ngưỡng; trường hợp ngoại lệ có đường chuyển người; quyền truy cập được cấu hình; có nhật ký; có quy trình khi mô hình hoặc dịch vụ lỗi.
Ghi nhớ trong 30 giây
- Một quy trình AI tốt phải có đầu vào, đầu ra, tiêu chí đúng và điểm dừng rõ ràng.
- Chỉ số chất lượng phải gắn với tác vụ; không có một “độ chính xác AI” chung cho mọi việc.
- Mỗi bước quan trọng cần biết ai chịu trách nhiệm, dữ liệu nào đã dùng và cách quay lại nguồn.
- Nếu không thể mô tả cách kiểm tra đầu ra thì chưa nên tự động hóa bước đó.
Nguồn tham khảo
- NIST – AI Risk Management Framework (AI RMF) 1.0 và AI RMF Playbook; NIST đang cập nhật AI RMF trong năm 2026 nên khi triển khai thực tế cần kiểm tra phiên bản hiện hành.
- NIST AI 600-1 – Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, 2024.
- ISO/IEC 42001:2023 – Artificial intelligence management system.
- RICS – Responsible use of artificial intelligence in surveying practice, 1st edition; có hiệu lực từ 09/03/2026.
Bài tiếp theo
Bài 03: Prompt không phải là tất cả: thiết kế ngữ cảnh, ràng buộc và cấu trúc đầu ra cho công việc BĐS