AI EngineeringKhông communicate được giới hạn LLM → user/PM expectations unrealistic → product disappoint → AI bị gán "không work".
Phrasing cho non-technical audience:
1. LLM không phải search engine hoặc database
- Cách nói: "LLM là mô hình xác suất — nó sinh câu trả lời 'nghe có vẻ đúng' dựa trên pattern trong dữ liệu, không phải lookup fact trong DB."
- Analogy: "Giống như một intern đọc rất nhiều sách nhưng trả lời bằng trí nhớ, không phải tra sách lại. Intern rất giỏi nhưng thi thoảng tự tin nói sai."
2. Hallucination là đặc trưng, không phải bug
- Cách nói: "Không có model nào 100% — GPT-4, Claude, Gemini đều hallucinate. Câu hỏi là giảm tỷ lệ xuống đủ thấp để an toàn dùng cho use case cụ thể."
- Dẫn chứng: Air Canada chatbot hallucinate policy → kiện → công ty phải pay. Lesson: không bao giờ để LLM trả lời unverified cho legal/financial advice.
3. Accuracy là spectrum, không binary
- Cách nói: "Thay vì hỏi 'AI có đúng không?', hỏi 'AI đúng 95% có chấp nhận được cho use case này không?'. Nếu rủi ro thấp (summarize nháp email) → 95% ok. Rủi ro cao (chẩn đoán y tế) → 99.99% vẫn có thể chưa đủ."
- Frame: human baseline — human agent customer support accurate 85-90%; nếu AI 93% thì đã tốt hơn human.
4. Knowledge cutoff
- Cách nói: "Model biết thế giới đến thời điểm X, không biết event sau đó. Dùng RAG để cung cấp thông tin mới."
5. Non-determinism
- Cách nói: "Cùng câu hỏi hỏi 2 lần có thể ra 2 câu trả lời khác (về wording, đôi khi về nội dung). Đây không phải bug — đây là cơ chế. Chúng ta control bằng temperature."
6. Cost và latency không free
- Cách nói: "Mỗi request có cost + latency. 'Thêm AI vào mọi chỗ' giống 'gọi lawyer mỗi lần ký' — đắt và chậm. Cần chọn nơi giá trị cao nhất."
7. Không reasoning thật sự
- Cách nói: "LLM rất giỏi pattern matching, nhưng yếu hơn human với reasoning phức tạp, toán khó, logic nhiều bước. Reasoning model (o1, Claude extended thinking) giúp nhưng vẫn giới hạn."
8. Bias và tone
- Cách nói: "Model learn từ internet → inherit bias. Cần eval và guardrail — đặc biệt với use case có thể discriminate."
Analogies hay dùng:
- "Intern có IQ cao nhưng không có trí nhớ và không tra được" — explains hallucination, cần RAG.
- "Nhân viên mới đọc manual" (với RAG) — chỉ biết trong tài liệu cho sẵn.
- "Assistant, không phải oracle" — luôn cần human review cho decision quan trọng.
- "Photoshop của text" — công cụ mạnh nhưng cần người biết dùng và verify kết quả.
Expectations setting:
1. Show real example có sai — đừng chỉ show best cases. Sếp thấy failure cases → trust cao hơn khi bạn nói "đã plan cho case này".
2. Tell the mitigation story — "hallucination 2% → RAG + citation + human review cho khi confidence thấp".
3. Compare vs baseline — AI vs current human process, không phải AI vs perfection.
4. Quantify risk × impact — cho risk thấp, 95% đủ; cho high impact, cần 99%+ với guardrail.
5. Phased rollout — canary → monitor → expand. Đừng ship big-bang full AI.
Script cho câu hỏi cụ thể:
> "Sao AI không 100%?"
> "AI dựa trên pattern statistical, không phải rule tuyệt đối. Giống dự báo thời tiết — rất chính xác nhưng không bao giờ 100%. Chúng ta mitigate bằng 3 lớp: RAG đưa fact thực vào context, guardrail detect câu trả lời bất thường, và human review cho case rủi ro cao. Với use case này, 97% accuracy đủ tốt vs human baseline 92%, và cost giảm 5x."
> "Khi nào AI sẽ hoàn hảo?"
> "Không bao giờ theo nghĩa 100%. Nhưng tăng steadily — 2 năm tới model có thể mạnh hơn 2-3x hiện tại. Chiến lược: ship bây giờ với guardrail, upgrade model khi chất lượng cải thiện, không đợi perfect."
> "Đối thủ đã dùng AI rồi sao ta chưa?"
> "Chúng ta đang build — nhưng làm đúng quan trọng hơn làm nhanh. Case study Samsung leak chip design qua ChatGPT, Air Canada bị kiện vì chatbot nói láo. Chúng ta có plan phased rollout với guardrail."
Common pitfall: engineer quá technical → lose audience; hoặc quá hype → set unrealistic expectation. Balance: rõ ràng về giới hạn + confident về mitigation + quantify.