Mở đầu — vì sao bài này quan trọng
Có một sự thật mà tôi muốn nói thẳng với bạn ngay từ đầu: bạn — một Product Manager — sẽ không bao giờ phải ngồi train một mô hình ngôn ngữ lớn (LLM). Đó là việc của ML engineer, của research scientist. Bạn không cần biết đạo hàm, không cần hiểu kiến trúc Transformer ở mức từng phép nhân ma trận, và càng không cần viết một dòng PyTorch nào.
Nhưng đây là chỗ nhiều PM hiểu sai. Họ nghĩ "tôi không phải dân kỹ thuật, nên tôi không cần hiểu LLM hoạt động ra sao, cứ dùng là được". Sai lầm này tốn rất nhiều tiền và uy tín. Tôi đã chứng kiến một PM cam kết với CEO rằng "AI sẽ trả lời chính xác 100% mọi câu hỏi của khách hàng" — bởi vì anh ấy không hiểu bản chất xác suất của LLM. Ba tháng sau, tính năng bị tắt vì chatbot bịa ra chính sách hoàn tiền không tồn tại.
AI literacy — hiểu biết cơ bản về cách LLM vận hành — là tầng nền tảng cho mọi việc bạn làm với AI trong vai trò PM. Nó không phải để bạn đi khoe thuật ngữ. Nó để bạn giao tiếp đúng với đội engineering, viết spec đúng cho tính năng AI, và đặt kỳ vọng đúng với sếp và khách hàng. Khi bạn hiểu LLM "thực sự là gì" thay vì coi nó là phép màu, bạn ra quyết định tỉnh táo hơn rất nhiều.
Bài này chính là tầng hiểu biết đó. Tôi sẽ giải thích LLM theo ngôn ngữ của một PM, không phải của một nhà nghiên cứu.
Khái niệm cốt lõi
LLM thực chất là một cỗ máy đoán từ tiếp theo
Hãy bắt đầu từ điều quan trọng nhất. Một LLM như GPT, Claude hay Gemini, ở tầng bản chất, làm đúng một việc: dự đoán từ tiếp theo (chính xác hơn là "token tiếp theo") dựa trên toàn bộ chuỗi văn bản trước đó.
Bạn gõ "Thủ đô của Việt Nam là...", mô hình tính toán xác suất cho từ tiếp theo và thấy "Hà Nội" có xác suất cao nhất, nên nó xuất ra "Hà Nội". Nó không "tra cứu" trong một cơ sở dữ liệu. Nó không "biết" theo nghĩa con người biết. Nó dự đoán dựa trên các mẫu (pattern) mà nó đã học từ hàng nghìn tỷ từ trong quá trình huấn luyện.
Nghe có vẻ đơn giản đến mức tầm thường, nhưng chính sự thật này giải thích gần như mọi hành vi kỳ lạ của AI mà bạn gặp. Vì sao AI đôi khi bịa thông tin? Vì nó đang đoán từ có xác suất cao chứ không phải kiểm chứng sự thật. Vì sao cùng một câu hỏi mà hai lần trả lời khác nhau? Vì có yếu tố ngẫu nhiên trong việc chọn từ.
Token — đơn vị mà LLM thực sự "nhìn thấy"
LLM không xử lý văn bản theo từ hay theo chữ cái, mà theo token — những mẩu văn bản nhỏ. Một token tiếng Anh trung bình khoảng 4 ký tự, hay tương đương 0,75 từ. Tiếng Việt với dấu thường tốn nhiều token hơn tiếng Anh cho cùng một ý — đây là chi tiết quan trọng khi bạn tính chi phí (bài về cost management sẽ đào sâu, ở đây bạn chỉ cần biết khái niệm).
Tại sao PM cần biết token? Vì hai lý do: chi phí được tính theo token, và giới hạn ngữ cảnh (context window) cũng đo bằng token. Mỗi mô hình chỉ "nhớ" được một lượng token nhất định trong một cuộc hội thoại — ví dụ 128.000 hay 200.000 token. Vượt quá, mô hình sẽ quên phần đầu. Khi đội bạn nói "model bị mất ngữ cảnh sau 20 trang tài liệu", bạn cần hiểu họ đang nói về giới hạn này.
Trọng số đã đóng băng — "kiến thức" của mô hình có hạn sử dụng
Khi một LLM được huấn luyện xong, "kiến thức" của nó bị đóng băng tại một thời điểm gọi là knowledge cutoff (mốc cắt kiến thức). Mô hình huấn luyện đến tháng 1/2025 sẽ không biết gì xảy ra sau đó, trừ khi bạn cung cấp thông tin mới trong prompt hoặc nối nó với công cụ tìm kiếm.
Đây là lý do vì sao khi bạn hỏi AI về một sự kiện vừa xảy ra tuần trước, nó có thể trả lời tự tin nhưng sai bét. Nó không "lười cập nhật" — nó đơn giản là không có dữ liệu đó.
Hai cách "dạy thêm" cho LLM: prompt, RAG và fine-tuning
Là PM, bạn sẽ liên tục nghe ba thuật ngữ này trong các cuộc họp với engineer. Hiểu sự khác biệt giúp bạn ra quyết định kiến trúc đúng:
- Prompting / In-context: Bạn nhét thông tin cần thiết thẳng vào câu lệnh. Rẻ, nhanh, linh hoạt, nhưng giới hạn bởi context window.
- RAG (Retrieval-Augmented Generation): Khi cần trả lời dựa trên tài liệu nội bộ (ví dụ 5.000 trang chính sách công ty), hệ thống sẽ tìm kiếm đoạn liên quan rồi đưa vào prompt cho LLM. Đây là cách phổ biến nhất để xây chatbot doanh nghiệp đáng tin.
- Fine-tuning: Huấn luyện lại mô hình trên dữ liệu của bạn để thay đổi "phong cách" hay "hành vi". Đắt, chậm, và thường không phải giải pháp đầu tiên — nhiều PM nhầm tưởng cứ gặp vấn đề là phải fine-tune.
Temperature — núm điều chỉnh độ "sáng tạo"
Có một tham số gọi là temperature quyết định mức độ ngẫu nhiên khi mô hình chọn từ. Temperature thấp (gần 0) khiến mô hình chọn từ chắc chắn nhất — phù hợp cho việc cần chính xác, nhất quán như phân loại hay trích xuất dữ liệu. Temperature cao khiến nó "phiêu" hơn — phù hợp cho brainstorm ý tưởng. PM không cần chỉnh tham số này tay, nhưng cần hiểu để spec đúng: "tính năng tóm tắt hợp đồng phải dùng temperature thấp để đảm bảo nhất quán".
Hallucination — không phải bug, mà là đặc tính
Vì LLM đoán từ có xác suất cao chứ không tra cứu sự thật, nó có thể tạo ra thông tin nghe rất trôi chảy nhưng hoàn toàn sai — gọi là hallucination (ảo giác). Đây không phải lỗi có thể "sửa hết" được; nó là hệ quả trực tiếp của cách LLM hoạt động. Bạn chỉ có thể giảm thiểu (qua RAG, qua kiểm chứng, qua thiết kế sản phẩm). Bài riêng về spotting hallucination sẽ dạy bạn cách phát hiện; ở đây điều cốt lõi cần nhớ là: đừng bao giờ thiết kế sản phẩm với giả định AI luôn đúng.
Tình huống thực tế
Tình huống 1: Chatbot CSKH của một sàn TMĐT tại TP.HCM
Một công ty thương mại điện tử cỡ vừa ở TP.HCM (gọi là ShopGo, doanh thu khoảng 200 tỷ/năm) muốn làm chatbot trả lời câu hỏi khách hàng. PM ban đầu yêu cầu đội kỹ thuật "fine-tune GPT trên toàn bộ dữ liệu sản phẩm" vì nghĩ đó là cách để AI "thuộc" hàng hóa.
Đội engineer phản đối, nhưng PM không hiểu đủ về LLM để đánh giá. Kết quả: ba tuần fine-tuning tốn khoảng 4.000 USD, và mô hình vẫn trả lời sai giá vì giá thay đổi hằng ngày — trong khi trọng số đã đóng băng từ lúc train xong.
Diễn giải: Vấn đề ở đây là "kiến thức cần liên tục cập nhật" (giá, tồn kho) — đúng bài toán của RAG, không phải fine-tuning. Một hệ thống RAG đơn giản truy vấn database giá real-time rồi đưa vào prompt sẽ giải quyết gọn ghẽ với chi phí thấp hơn nhiều.
Bài học: Nếu PM hiểu sự khác biệt giữa "mô hình cần biết thêm sự thật thay đổi liên tục" (RAG) và "mô hình cần đổi hành vi" (fine-tune), công ty đã tiết kiệm cả tháng và mấy nghìn đô. AI literacy không phải kiến thức trang trí — nó là tiền thật.
Tình huống 2: Tính năng "tóm tắt feedback" bị mất ngữ cảnh
Một startup SaaS ở Singapore xây tính năng cho phép PM dán toàn bộ phản hồi khách hàng vào AI để tóm tắt. Đội build xong, demo nội bộ chạy ngon với 30 phản hồi. Nhưng khi khách hàng thật dán 800 phản hồi, bản tóm tắt bỏ sót hoàn toàn các phản hồi ở đầu danh sách.
PM hốt hoảng báo "AI bị lỗi". Engineer giải thích: 800 phản hồi vượt context window của mô hình đang dùng, nên phần đầu bị cắt mất, AI chỉ tóm tắt phần cuối.
Diễn giải: Đây không phải bug code, mà là giới hạn cố hữu của LLM. Giải pháp đúng là chunking (chia nhỏ) — tóm tắt từng nhóm rồi tóm tắt lại các bản tóm tắt, hoặc đổi sang mô hình có context window lớn hơn.
Bài học: Nếu PM hiểu khái niệm context window ngay từ giai đoạn spec, họ đã định nghĩa rõ "hệ thống phải xử lý tới N phản hồi" và đội đã chọn kiến trúc phù hợp ngay từ đầu thay vì vá lỗi gấp lúc khách hàng phàn nàn.
Tình huống 3: Trả lời tự tin nhưng sai về luật mới
Một PM tại một fintech ở Hà Nội dùng AI để soạn nội dung giải thích quy định mới của Ngân hàng Nhà nước vừa ban hành tháng trước. AI viết một đoạn rất mạch lạc, trích dẫn cả "số hiệu thông tư" nghe rất thật. PM suýt đăng lên blog công ty.
May mắn, một đồng nghiệp pháp chế kiểm tra và phát hiện: số thông tư đó không tồn tại. Mô hình đã hallucinate, và lý do gốc rễ là quy định mới nằm sau knowledge cutoff của mô hình.
Diễn giải: Mô hình không "nói dối có chủ đích". Nó đoán ra một định dạng số thông tư trông hợp lý vì trong dữ liệu huấn luyện có vô số văn bản dạng đó. Không có dữ liệu thật, nó vẫn tạo ra thứ "nghe giống thật".
Bài học: Với nội dung nhạy cảm (pháp lý, y tế, tài chính), AI literacy buộc PM thiết kế quy trình kiểm chứng bắt buộc bởi con người. Hiểu knowledge cutoff và hallucination không phải để sợ AI, mà để biết đặt nó vào đúng chỗ — trợ lý soạn nháp, không phải nguồn sự thật cuối cùng.
Hướng dẫn từng bước
Đây là lộ trình để bạn xây nền AI literacy đủ dùng cho công việc PM, không quá ít cũng không sa đà:
- Nắm vững một câu thần chú: "LLM là cỗ máy đoán token tiếp theo dựa trên xác suất". Mỗi khi gặp hành vi lạ của AI, hãy quay về câu này — nó giải thích được phần lớn.
- Tự kiểm chứng bằng tay: Mở ChatGPT/Claude, hỏi cùng một câu hỏi 3 lần với temperature mặc định. Quan sát câu trả lời khác nhau như thế nào. Bạn vừa "thấy" tính xác suất bằng mắt mình.
- Thử chạm giới hạn context: Dán một văn bản thật dài và yêu cầu tóm tắt, rồi hỏi về chi tiết ở đoạn đầu. Khi nó bỏ sót, bạn đã cảm nhận được context window thực tế.
- Test knowledge cutoff: Hỏi AI về một sự kiện rất gần đây mà bạn biết chắc. Nếu nó trả lời sai hoặc nói "tôi không có thông tin sau thời điểm X", bạn vừa xác định được mốc cắt kiến thức.
- Lập bảng phân biệt RAG vs Fine-tune vs Prompt: Với mỗi tính năng AI bạn định làm, tự hỏi: "Vấn đề là thiếu sự thật, hay sai hành vi?". Câu trả lời quyết định kiến trúc.
- Học từ vựng cầu nối với engineer: token, context window, temperature, RAG, fine-tune, knowledge cutoff, hallucination, embedding. Bạn không cần định nghĩa hàn lâm, chỉ cần dùng đúng trong câu để đối thoại trôi chảy với đội kỹ thuật.
- Áp dụng vào một spec thật: Lần tới khi viết yêu cầu cho tính năng AI, thêm một mục "Giả định về mô hình" — nêu rõ kỳ vọng về độ chính xác, cách xử lý hallucination, và giới hạn dữ liệu.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi AI là cơ sở tri thức tuyệt đối. Nhiều PM thiết kế sản phẩm với giả định ngầm "AI luôn trả lời đúng". Mẹo: luôn hỏi "nếu AI sai ở đây thì hậu quả là gì?" và thiết kế lớp phòng vệ tương ứng.
Lỗi 2 — Lạm dụng từ fine-tune. Cứ gặp vấn đề là đề xuất fine-tune, trong khi 80% trường hợp prompt tốt hoặc RAG đã đủ. Mẹo: fine-tune là lựa chọn cuối, không phải đầu tiên.
Lỗi 3 — Học quá sâu kỹ thuật không cần thiết. Một số PM lao vào học backpropagation, attention math rồi nản và bỏ. Mẹo: dừng ở tầng "đủ để giao tiếp và spec". Bạn không thi tuyển ML engineer.
Lỗi 4 — Nhầm "AI không biết" với "AI bị lỗi". Khi AI trả lời sai về sự kiện mới, đó thường là knowledge cutoff chứ không phải bug. Mẹo: trước khi báo lỗi cho đội, kiểm tra xem thông tin có nằm sau mốc cắt kiến thức không.
Lỗi 5 — Bỏ qua tính ngẫu nhiên khi test. Test một lần thấy đúng rồi kết luận "ổn". Mẹo: với tính năng quan trọng, test cùng input nhiều lần để thấy độ dao động của output.
Mẹo vàng: Khi nói chuyện với engineer, hãy mô tả vấn đề theo hành vi mong muốn của sản phẩm ("tôi cần câu trả lời nhất quán, ít bịa") thay vì áp đặt giải pháp kỹ thuật ("hãy fine-tune"). Hiểu LLM giúp bạn mô tả vấn đề đúng tầng, để engineer chọn giải pháp tối ưu.
Bài tập thực hành
- Bài tập "nhìn thấy xác suất": Chọn một câu hỏi mở (ví dụ "Gợi ý tên cho một app giao đồ ăn"). Hỏi AI 5 lần, ghi lại 5 câu trả lời. Viết một đoạn ngắn (3–4 câu) giải thích vì sao chúng khác nhau, dùng đúng khái niệm "đoán token theo xác suất".
- Bài tập phân loại kiến trúc: Lấy 3 ý tưởng tính năng AI cho sản phẩm của bạn. Với mỗi ý tưởng, ghi rõ nên dùng Prompt, RAG hay Fine-tune và lý do bằng một câu. Tự chấm: bạn có phân biệt được "thiếu sự thật" với "sai hành vi" không?
- Bài tập săn hallucination: Hỏi AI về một chủ đề rất hẹp mà bạn là chuyên gia (lĩnh vực sản phẩm của bạn, hoặc một sự kiện gần đây bạn rành). Tìm ít nhất một chỗ AI nói sai hoặc bịa. Ghi lại và phân tích: lỗi do hallucination hay do knowledge cutoff?
- Bài tập spec mini: Viết mục "Giả định về mô hình" dài nửa trang cho một tính năng AI giả định của bạn, nêu rõ kỳ vọng độ chính xác, cách xử lý khi AI sai, và giới hạn dữ liệu/ngữ cảnh.
Tóm tắt
Là PM, bạn không cần build LLM, nhưng bạn bắt buộc phải hiểu đủ để giao tiếp với đội kỹ thuật và spec tính năng AI đúng đắn. Hãy nhớ những trụ cột này:
- LLM về bản chất là cỗ máy đoán token tiếp theo theo xác suất, không phải cơ sở tri thức tra cứu.
- Token và context window quyết định chi phí và lượng thông tin mô hình "nhớ" được.
- Knowledge cutoff khiến mô hình không biết gì sau mốc huấn luyện — đừng nhầm với lỗi.
- Hallucination là đặc tính cố hữu, chỉ giảm thiểu được chứ không xóa bỏ; đừng thiết kế sản phẩm với giả định AI luôn đúng.
- Phân biệt Prompt / RAG / Fine-tune: thiếu sự thật thì RAG, sai hành vi mới cân nhắc fine-tune, còn lại prompt giải quyết phần lớn.