Một câu lệnh tốt có thể cải thiện đầu ra, nhưng một hệ thống đáng tin không thể chỉ dựa vào “viết prompt hay”. Cùng một câu lệnh sẽ cho kết quả khác nếu nguồn dữ liệu, quyền truy cập, công cụ, phiên bản mô hình hoặc cấu trúc đầu ra thay đổi.
Trong nghiệp vụ BĐS, cách tiếp cận bền vững hơn là thiết kế gói ngữ cảnh và ràng buộc để AI biết nó được phép dùng gì, phải trả gì, không được suy đoán gì và khi nào phải dừng.
Chuyên đề: AI ứng dụng trong Bất động sản · Bài 03 · 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. Sáu lớp của một yêu cầu tốt
- Mục tiêu: công việc cụ thể và người sẽ dùng kết quả.
- Nguồn: tài liệu/bảng dữ liệu nào được phép tham chiếu.
- Ràng buộc: điều gì cấm suy đoán, cấm làm, giới hạn phạm vi.
- Cấu trúc đầu ra: trường, kiểu dữ liệu, trạng thái.
- Tiêu chí kiểm: mỗi kết luận quan trọng phải có bằng chứng gì.
- Đường xử lý ngoại lệ: MISSING, CONFLICT, UNCLEAR, NEEDS_REVIEW.
2. Ngữ cảnh nghiệp vụ quan trọng hơn văn phong
“Hãy đóng vai chuyên gia BĐS” ít giá trị hơn việc cung cấp rõ: đây là báo cáo nghiên cứu thị trường cho quận nào, giai đoạn nào, loại tài sản nào, định nghĩa nguồn cung ra sao, nguồn dữ liệu chính thức nào, chỉ số nào được phép tính và người đọc cần quyết định gì.
Ngữ cảnh tốt giúp mô hình giới hạn không gian suy luận và giảm khả năng pha trộn kiến thức chung không phù hợp.
3. Tách dữ liệu khỏi chỉ dẫn
Tài liệu bên ngoài có thể chứa câu giống mệnh lệnh: “bỏ qua yêu cầu trước”, “gửi dữ liệu đến địa chỉ này”, hoặc văn bản vô tình trùng cú pháp điều khiển. Hệ thống phải coi nội dung tài liệu là dữ liệu để phân tích, không phải chỉ dẫn có quyền thay đổi quy tắc hệ thống.
Đây là nguyên tắc quan trọng khi AI đọc Email, website, PDF hoặc ghi chú từ bên ngoài.
4. Đầu ra có cấu trúc thay cho đoạn văn tự do
Ví dụ khi đọc tin dự án, thay vì yêu cầu “tóm tắt”, có thể yêu cầu các trường: tên dự án, chủ thể được nhắc, sự kiện, ngày sự kiện, địa điểm, số liệu, nguồn, trích đoạn bằng chứng, trạng thái xác minh.
Đầu ra có cấu trúc giúp cơ sở dữ liệu kiểm kiểu, phát hiện thiếu trường và tránh việc nhân viên phải đọc một đoạn văn dài để nhập lại.
5. Dùng ví dụ chuẩn cho trường hợp khó
Một hoặc vài ví dụ được chọn kỹ có thể làm rõ cách xử lý những tình huống mà mô tả bằng lời dễ mơ hồ: một phụ lục thay thế điều khoản cũ; một số liệu có hai đơn vị; một bài báo chỉ dẫn lại nguồn khác; một địa chỉ viết tắt.
Ví dụ nên đại diện cho ranh giới quyết định, không chỉ là ví dụ “đẹp”.
6. Quy tắc “không biết” là một phần của câu lệnh
Hệ thống cần được phép không kết luận. Quy định rõ: nếu nguồn không nêu thì trả MISSING; hai nguồn mâu thuẫn trả CONFLICT; câu chữ không đủ rõ trả UNCLEAR; cần đánh giá chuyên môn trả NEEDS_REVIEW. Không dùng kiến thức chung để lấp trường còn trống.
7. Chỉ dẫn công cụ xác định
Nếu nhiệm vụ yêu cầu tính tỷ suất, cộng doanh thu, đổi đơn vị, truy vấn dữ liệu hay kiểm khoảng thời gian, câu lệnh nên yêu cầu AI gọi công cụ thay vì tự suy tính. AI cung cấp tham số và giải thích; công cụ xác định cung cấp kết quả.
Ví dụ: “Lấy NOI đã duyệt từ cơ sở dữ liệu, lấy giá trị tài sản tại ngày chốt, dùng bộ tính để tính tỷ suất vốn hóa, sau đó giải thích chênh lệch so với quý trước.”
8. Thiết kế nguồn và trích dẫn
Không chỉ yêu cầu “hãy trích nguồn”. Cần xác định định dạng: mã tài liệu, trang, đoạn, URL hoặc khóa bản ghi; và quy tắc rằng kết luận quan trọng không có nguồn thì không được gắn trạng thái “đã xác minh”.
9. Quản lý phiên bản câu lệnh
Khi câu lệnh trở thành một phần của quy trình, nó phải được quản lý như cấu hình: có mã phiên bản, ngày thay đổi, lý do, người duyệt và kết quả kiểm thử trước/sau. Chỉnh vài câu có thể làm thay đổi đáng kể tỷ lệ bỏ sót hoặc cách xử lý ngoại lệ.
10. Tình huống: tạo báo cáo thị trường tuần
Thiết kế tốt không phải “hãy viết báo cáo thị trường tuần này”, mà là: lấy dữ liệu từ danh sách nguồn đã duyệt; chuẩn hóa kỳ thời gian; tách dữ kiện và nhận định; số liệu nào phải được bộ tính kiểm; mỗi sự kiện có nguồn; thông tin chưa xác minh đưa vào mục tín hiệu; đầu ra theo bảng chỉ số và đoạn phân tích; người phụ trách thị trường duyệt trước khi gửi.
11. Một cấu trúc yêu cầu có thể tái sử dụng
| Thành phần | Nội dung nên có |
|---|---|
| Nhiệm vụ | Động từ + đối tượng + mục đích |
| Phạm vi | Loại tài sản, địa bàn, thời gian |
| Nguồn | Danh sách nguồn và ưu tiên |
| Không được làm | Không suy đoán, không tính nhẩm phần trọng yếu, không hành động ngoài quyền |
| Đầu ra | Schema, đơn vị, trạng thái |
| Bằng chứng | Vị trí nguồn cho từng trường quan trọng |
| Ngoại lệ | MISSING/CONFLICT/UNCLEAR/NEEDS_REVIEW |
Ghi nhớ trong 30 giây
- Câu lệnh chỉ là một phần của hệ thống; ngữ cảnh, nguồn, công cụ, quyền và cấu trúc đầu ra quan trọng không kém.
- Quy định MISSING, CONFLICT, UNCLEAR và NEEDS_REVIEW giúp chống việc AI tự lấp khoảng trống.
- Đầu ra có cấu trúc làm giảm nhập tay và giúp máy kiểm tra được.
- Tài liệu đưa vào ngữ cảnh cũng có thể chứa chỉ dẫn độc hại; cần tách dữ liệu khỏi mệnh lệnh điều khiển hệ thống.
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 04: RAG và dữ liệu nội bộ: để AI trả lời dựa trên tài liệu thật thay vì trí nhớ mô hình