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.
Failing to communicate LLM limits → user/PM expectations get unrealistic → product disappoints → AI gets labeled "broken".
Phrasing for non-technical audiences:
1. LLMs are not search engines or databases
- Phrasing: "LLMs are probabilistic models — they generate "plausible-sounding" answers from data patterns, not DB lookups."
- Analogy: "Like an intern who has read a lot of books and answers from memory, not from looking the book back up. The intern is sharp but occasionally confidently wrong."
2. Hallucination is a feature, not a bug
- Phrasing: "No model is 100% — GPT-4, Claude, Gemini all hallucinate. The question is reducing the rate low enough for the specific use case."
- Case: Air Canada chatbot hallucinated a policy → lawsuit → company paid. Lesson: never let an LLM answer unverified for legal/financial advice.
3. Accuracy is a spectrum, not binary
- Phrasing: "Instead of asking 'is the AI right?', ask 'is 95% good enough for this use case?'. Low risk (draft email summary) → 95% is fine. High risk (medical diagnosis) → even 99.99% may be too low."
- Frame: human baseline — a human support agent is accurate 85–90%; if AI is 93% it already beats humans.
4. Knowledge cutoff
- Phrasing: "The model knows the world up to date X, nothing after. Use RAG to provide fresh info."
5. Non-determinism
- Phrasing: "The same question asked twice can produce two different answers (wording, sometimes content). It's not a bug — it's the mechanism. We control it with temperature."
6. Cost and latency aren't free
- Phrasing: "Every request has cost + latency. 'Add AI everywhere' is like 'call a lawyer every signature' — expensive and slow. Pick highest-value spots."
7. No true reasoning
- Phrasing: "LLMs are great at pattern matching but weaker than humans at complex reasoning, hard math, multi-step logic. Reasoning models (o1, Claude extended thinking) help but still limited."
8. Bias and tone
- Phrasing: "Models learn from the internet → inherit biases. Evaluation and guardrails are essential — especially for use cases that can discriminate."
Popular analogies:
- "A smart intern with no memory and no lookup" — explains hallucination, motivates RAG.
- "New hire reading the manual" (with RAG) — only knows what's in the provided docs.
- "Assistant, not oracle" — always needs human review for important decisions.
- "Photoshop for text" — powerful tool but needs a skilled user to verify output.
Setting expectations:
1. Show real failure examples — don't only show best cases. Bosses who see failure modes trust you more when you say "we planned for this".
2. Tell the mitigation story — "hallucination 2% → RAG + citation + human review for low-confidence cases".
3. Compare vs baseline — AI vs the current human process, not AI vs perfection.
4. Quantify risk × impact — low risk, 95% is enough; high impact, 99%+ with guardrails.
5. Phased rollout — canary → monitor → expand. Don't big-bang.
Scripts for common questions:
> "Why isn't AI 100%?"
> "AI is statistical pattern matching, not absolute rule. Like weather forecasts — very accurate, but never 100%. We mitigate with 3 layers: RAG puts real facts into context, guardrails detect anomalous answers, and human review for high-risk cases. For this use case, 97% beats the human baseline of 92% at 5x lower cost."
> "When will AI be perfect?"
> "Never at literal 100%. But it improves steadily — the next 2 years will bring 2–3x stronger models. Strategy: ship now with guardrails, upgrade as quality improves, don't wait for perfect."
> "Competitors already use AI. Why aren't we?"
> "We're building — but doing it right matters more than doing it fast. Samsung leaked chip designs via ChatGPT, Air Canada got sued over a lying chatbot. We have a phased rollout plan with guardrails."
Common pitfall: engineers get too technical → lose the audience; or too hype → set unrealistic expectations. Balance: clear limits + confident mitigation + quantified metrics.