Mở đầu — vì sao bài này quan trọng
Trong những bài trước, bạn đã làm quen với RPA, với các nền tảng workflow như Zapier, Make, n8n, và với khái niệm intelligent automation. Tất cả những công cụ đó đều rất mạnh, nhưng chúng có một điểm yếu chung: chúng giỏi xử lý dữ liệu có cấu trúc (structured data) — những thứ nằm gọn gàng trong ô Excel, trong trường của database, trong API trả về JSON. Còn thế giới thực thì lại đầy ắp dữ liệu phi cấu trúc (unstructured data): email khách hàng viết lan man, biên bản họp dài ba trang, hợp đồng PDF, tin nhắn Zalo của người dùng. Đây chính là vùng đất mà tự động hóa truyền thống "bó tay".
Và đây cũng chính là chỗ LLM — Large Language Model (mô hình ngôn ngữ lớn) — bước vào và thay đổi cuộc chơi. Một LLM như GPT, Claude hay Llama có khả năng "đọc hiểu" ngôn ngữ tự nhiên, suy luận, tóm tắt, phân loại, và sinh ra văn bản như con người. Khi bạn cắm khả năng này vào một quy trình tự động, bạn không còn chỉ tự động hóa những tác vụ máy móc nữa — bạn bắt đầu tự động hóa cả những tác vụ vốn cần "trí óc".
Bài này tập trung hẹp vào vai trò của LLM như một thành phần (component) bên trong quy trình tự động hóa: nó làm được gì, ghép vào workflow ra sao, và các use case kinh điển. Chúng ta sẽ không đi sâu vào AI agent tự hành (đó là Bài 26), vào RAG (Bài 30), hay chatbot (Bài 24) — những chủ đề đó có bài riêng. Ở đây, hãy coi LLM như một "nhân viên ảo biết đọc viết" mà bạn gọi đến mỗi khi quy trình cần xử lý ngôn ngữ.
Khái niệm cốt lõi
LLM là gì trong ngữ cảnh automation?
Hãy quên đi những định nghĩa hàn lâm. Trong automation, bạn nên hình dung LLM như một hàm (function) đặc biệt: bạn đưa vào một đoạn văn bản (gọi là prompt), nó trả về một đoạn văn bản khác. Khác với hàm lập trình thông thường vốn cho kết quả cố định, LLM "hiểu" ngữ nghĩa của input và tạo ra output linh hoạt dựa trên hàng tỉ tham số đã được huấn luyện.
Điều khiến LLM hữu dụng cho tự động hóa là nó xử lý được những việc mà bạn không thể viết quy tắc cứng (rule) để giải quyết. Bạn không thể viết if-else để tóm tắt một email, nhưng bạn có thể bảo LLM: "Tóm tắt email sau trong 2 câu". Đó là sự khác biệt về bản chất.
Ba dòng mô hình bạn cần phân biệt
GPT (OpenAI) — Dòng mô hình phổ biến nhất, truy cập qua API của OpenAI hoặc qua Azure OpenAI Service. Mạnh, đa năng, hệ sinh thái công cụ rộng. Phù hợp khi bạn cần độ chín và tài liệu phong phú.
Claude (Anthropic) — Nổi bật ở khả năng xử lý văn bản dài (context window lớn — có thể nhét cả tài liệu hàng trăm trang vào một lần gọi), khả năng tuân thủ chỉ dẫn chặt chẽ, và xu hướng "an toàn" hơn khi từ chối các yêu cầu mơ hồ. Rất hợp với các tác vụ trích xuất, phân tích tài liệu dài trong doanh nghiệp.
Llama (Meta) — Đây là dòng open-source / open-weight, nghĩa là bạn có thể tải về và tự host trên máy chủ của mình. Điểm này cực kỳ quan trọng với các ngành nhạy cảm dữ liệu như ngân hàng, y tế, chính phủ ở Việt Nam — nơi dữ liệu khách hàng không được phép gửi ra API nước ngoài. Đổi lại, bạn phải tự lo hạ tầng GPU và vận hành.
Quy tắc ngón tay cái: GPT/Claude khi bạn ưu tiên chất lượng và tốc độ triển khai; Llama khi bạn ưu tiên kiểm soát dữ liệu và chi phí dài hạn.
Bốn use case kinh điển của LLM trong workflow
Đây là phần xương sống của bài. Bốn nhóm việc dưới đây chiếm phần lớn các ứng dụng LLM trong tự động hóa quy trình thực tế.
1. Email triage và soạn thảo phản hồi (Email triage + draft response). LLM đọc email đến, phân loại theo chủ đề/độ ưu tiên/cảm xúc, định tuyến tới đúng phòng ban, và soạn sẵn một bản nháp trả lời để nhân viên chỉ cần kiểm tra rồi gửi. Đây là use case mang lại ROI rõ rệt nhất cho các đội chăm sóc khách hàng.
2. Tóm tắt cuộc họp / tài liệu (Summarize). Đưa bản ghi (transcript) cuộc họp hoặc một tài liệu dài, LLM rút ra các điểm chính, quyết định đã chốt, và đầu việc cần làm (action items). Tiết kiệm hàng giờ đọc lại.
3. Trích xuất dữ liệu có cấu trúc từ phi cấu trúc (Extract structured data). Đây có lẽ là use case "vàng" trong automation. Bạn đưa vào một đoạn văn bản tự do — ví dụ một email đặt hàng — và yêu cầu LLM trả về JSON với các trường rõ ràng: tên khách, sản phẩm, số lượng, địa chỉ. Output có cấu trúc này sau đó được đẩy thẳng vào các bước workflow tiếp theo (ghi database, gọi API). LLM trở thành "cầu nối" biến hỗn loạn thành ngăn nắp.
4. Phân loại và định tuyến (Classify + route). LLM gán nhãn cho nội dung: ticket này thuộc loại "khiếu nại" hay "hỏi thông tin"? Bình luận này tích cực hay tiêu cực? Hồ sơ này thuộc nhóm rủi ro nào? Dựa trên nhãn đó, workflow rẽ nhánh tự động.
LLM ghép vào workflow ở đâu?
Trong một workflow (Zapier, Make, n8n hay code), LLM thường đóng vai trò một bước xử lý ở giữa: Trigger (email đến) → LLM step (phân loại + trích xuất) → Logic (rẽ nhánh theo nhãn) → Action (ghi CRM, gửi thông báo). LLM không thay thế cả workflow; nó là "bộ não ngôn ngữ" được gọi đúng lúc cần hiểu văn bản. Phần còn lại của quy trình vẫn do các công cụ tự động hóa truyền thống đảm nhiệm.
Tình huống thực tế
Ví dụ 1 — Sàn TMĐT xử lý 8.000 email khách hàng mỗi ngày
Một công ty thương mại điện tử tầm trung tại TP.HCM (gọi là "ShopViet") mỗi ngày nhận khoảng 8.000 email từ khách: hỏi tình trạng đơn hàng, khiếu nại giao chậm, yêu cầu hoàn tiền, hỏi sản phẩm. Trước đây, 12 nhân viên CSKH phải đọc thủ công, mất trung bình 4 phút mỗi email chỉ để phân loại và viết câu trả lời chuẩn.
Họ xây một workflow: email đến → gọi LLM (Claude qua API) với prompt yêu cầu trả về JSON gồm 3 trường: loai (đơn hàng / khiếu nại / hoàn tiền / hỏi sản phẩm), do_uu_tien (cao / trung bình / thấp), và ban_nhap_tra_loi. Workflow đẩy email khiếu nại ưu tiên cao lên đầu hàng đợi, và gắn sẵn bản nháp để nhân viên chỉ việc rà soát.
Kết quả sau 3 tháng: thời gian xử lý mỗi email giảm từ 4 phút xuống 1,2 phút; đội CSKH xử lý được lượng email tăng 40% mà không tuyển thêm người. Quan trọng: họ không để LLM tự gửi email — bản nháp luôn qua mắt người duyệt.
Bài học rút ra: Sức mạnh thật sự nằm ở việc kết hợp LLM (hiểu + soạn nháp) với human-in-the-loop (con người duyệt cuối). LLM lo phần nặng nhọc, con người giữ trách nhiệm chất lượng và pháp lý.
Ví dụ 2 — Công ty bảo hiểm trích xuất dữ liệu từ đơn yêu cầu bồi thường
Một công ty bảo hiểm ở Hà Nội nhận đơn yêu cầu bồi thường (claim) qua nhiều định dạng: form web, email mô tả tự do, ảnh chụp giấy viết tay được OCR thành text. Vấn đề: dữ liệu vào hệ thống core rất lộn xộn, nhân viên nhập liệu phải đọc và gõ lại thủ công, sai sót cao.
Họ dùng LLM ở bước trích xuất: đầu vào là đoạn văn bản claim tự do, prompt yêu cầu trả về JSON chuẩn gồm ho_ten, so_hop_dong, ngay_xay_ra_su_co, loai_su_co, so_tien_yeu_cau, và tom_tat_su_viec. Nếu thiếu trường nào, LLM trả về null thay vì bịa. JSON này được kiểm tra hợp lệ rồi đẩy vào hệ thống.
Vì dữ liệu khách hàng nhạy cảm và phải tuân thủ quy định lưu trữ trong nước, ban đầu họ cân nhắc dùng GPT qua API nhưng cuối cùng chọn Llama tự host trên server đặt tại Việt Nam cho dữ liệu định danh, chỉ dùng API ngoài cho dữ liệu đã ẩn danh. Tỷ lệ nhập liệu sai giảm hơn một nửa, thời gian xử lý mỗi claim giảm khoảng 35%.
Bài học rút ra: Khi dữ liệu nhạy cảm, lựa chọn mô hình không chỉ là chuyện chất lượng — đó là chuyện tuân thủ (compliance) và chủ quyền dữ liệu. Llama open-weight cho bạn quyền giữ dữ liệu trong nhà.
Ví dụ 3 — Phòng dự án tóm tắt họp tự động
Một công ty phần mềm gia công (như mô hình của nhiều công ty outsourcing Việt Nam) có hàng chục cuộc họp dự án mỗi tuần với khách nước ngoài. Project Manager mất rất nhiều thời gian viết biên bản và lọc đầu việc.
Họ ghép một workflow đơn giản: file ghi âm họp → công cụ chuyển giọng nói thành văn bản (speech-to-text) → LLM tóm tắt với prompt cố định: "Từ transcript dưới đây, trả về (1) tóm tắt 5 gạch đầu dòng, (2) danh sách quyết định đã chốt, (3) action items kèm người phụ trách nếu có nêu tên". Kết quả được tự động đăng vào kênh dự án.
Mỗi PM tiết kiệm khoảng 3–4 giờ/tuần. Tuy nhiên họ phát hiện LLM đôi khi "gán" action item cho nhầm người khi transcript không rõ tên — nên họ thêm một dòng vào prompt: "Nếu không chắc ai phụ trách, để trống thay vì đoán".
Bài học rút ra: LLM rất giỏi tóm tắt, nhưng nó có xu hướng "lấp đầy khoảng trống" bằng phỏng đoán. Một câu chỉ dẫn nhỏ trong prompt ("không chắc thì để trống") cải thiện độ tin cậy đáng kể.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng để đưa LLM vào một workflow tự động hóa cụ thể.
Bước 1 — Chọn đúng việc cho LLM. Hỏi: "Bước này có cần hiểu ngôn ngữ tự nhiên không?" Nếu chỉ là sao chép trường dữ liệu hay tính toán, dùng tool thường — rẻ và đáng tin hơn. Chỉ dùng LLM khi đầu vào là văn bản tự do cần đọc hiểu, tóm tắt, phân loại hoặc sinh văn bản.
Bước 2 — Chọn mô hình. Cân nhắc ba yếu tố: chất lượng (GPT/Claude thường nhỉnh hơn cho tác vụ khó), chi phí (tính theo token — đoạn càng dài càng đắt), và yêu cầu dữ liệu (nhạy cảm → cân nhắc Llama tự host). Với phần lớn dự án mới, hãy bắt đầu bằng API của GPT hoặc Claude để chạy thử nhanh, rồi tối ưu sau.
Bước 3 — Viết prompt rõ ràng. Một prompt tốt gồm: (a) vai trò ("Bạn là trợ lý phân loại email"), (b) nhiệm vụ cụ thể, (c) định dạng output mong muốn (nói rõ "trả về JSON với các trường..."), và (d) ví dụ mẫu nếu cần (kỹ thuật này gọi là few-shot). Càng rõ ràng, output càng ổn định.
Bước 4 — Ép output có cấu trúc. Nếu workflow cần dùng kết quả ở bước sau, hãy yêu cầu LLM trả về JSON và quy định rõ schema. Nhiều API hỗ trợ chế độ "JSON mode" hoặc "structured output" để đảm bảo định dạng đúng — hãy bật nó lên.
Bước 5 — Gắn vào workflow và validate. Đặt LLM step vào giữa pipeline. Sau khi nhận output, luôn kiểm tra hợp lệ trước khi dùng: JSON có đúng cấu trúc không? Trường bắt buộc có không? Nếu sai, cho retry hoặc đẩy sang xử lý thủ công.
Bước 6 — Thêm human-in-the-loop ở chỗ rủi ro cao. Với hành động có hậu quả (gửi email cho khách, duyệt chi tiền, ghi vào hệ thống core), hãy chèn một bước con người duyệt. Đừng để LLM tự ý thực thi hành động không thể đảo ngược.
Bước 7 — Đo lường và lặp. Theo dõi tỉ lệ output đúng, chi phí token, thời gian tiết kiệm. Tinh chỉnh prompt dựa trên các trường hợp sai thực tế. Automation với LLM là một quá trình cải tiến liên tục, không phải "cài đặt một lần xong quên".
Lỗi thường gặp & mẹo
Lỗi 1 — Tin LLM tuyệt đối, không validate. LLM có thể "ảo giác" (hallucination) — bịa ra thông tin nghe rất thật. Đừng bao giờ đẩy thẳng output vào hệ thống quan trọng mà không kiểm tra. Mẹo: luôn có bước validate và một ngưỡng để rớt sang xử lý người.
Lỗi 2 — Prompt mơ hồ. "Xử lý email này" sẽ cho kết quả lung tung. Mẹo: viết prompt như viết hướng dẫn cho một nhân viên mới — cụ thể nhiệm vụ, cụ thể định dạng, cho ví dụ.
Lỗi 3 — Gửi dữ liệu nhạy cảm ra API ngoài mà không cân nhắc. Nhiều đội vô tư gửi số CMND, thông tin tài khoản khách hàng lên API nước ngoài — vi phạm chính sách bảo mật và pháp lý. Mẹo: ẩn danh dữ liệu trước khi gửi, hoặc dùng mô hình tự host cho dữ liệu định danh.
Lỗi 4 — Bỏ qua chi phí. LLM tính tiền theo token. Một workflow xử lý 8.000 email/ngày với prompt dài có thể tốn chi phí đáng kể. Mẹo: dùng mô hình nhỏ/rẻ cho việc đơn giản (phân loại), mô hình lớn cho việc khó (soạn thảo phức tạp); rút gọn prompt; cache những kết quả lặp lại.
Lỗi 5 — Output không ổn định giữa các lần chạy. Cùng input đôi khi cho output khác nhau. Mẹo: yêu cầu định dạng chặt, dùng JSON mode, và giảm "độ ngẫu nhiên" (tham số temperature thấp) cho các tác vụ cần nhất quán.
Lỗi 6 — Dùng LLM cho việc lẽ ra dùng code. LLM không phải búa vạn năng. Tính tổng đơn hàng, so sánh số — dùng code, đừng dùng LLM. Mẹo: LLM cho ngôn ngữ, code cho logic và số học.
Bài tập thực hành
Bài 1 — Thiết kế prompt trích xuất. Lấy 3 email đặt hàng tự do (tự bịa nội dung lộn xộn, ví dụ: "Chị ơi cho em đặt 2 cái áo thun đen size L giao về 12 Lê Lợi Q1 nhé, sđt 0901..."). Viết một prompt yêu cầu LLM trả về JSON gồm: ten_san_pham, so_luong, size, dia_chi, sdt. Chạy thử trên ChatGPT/Claude và chỉnh prompt đến khi cả 3 đều ra JSON đúng.
Bài 2 — Phân loại + định tuyến. Viết prompt phân loại 5 tin nhắn khách hàng thành 3 nhóm: "Khiếu nại", "Hỏi thông tin", "Khen ngợi". Yêu cầu output kèm do_uu_tien. Vẽ sơ đồ workflow: tin nhắn → LLM phân loại → rẽ nhánh (khiếu nại → đội xử lý gấp; còn lại → hàng đợi thường).
Bài 3 — So sánh mô hình. Lấy một đoạn văn bản tiếng Việt dài (ví dụ một bản tin) và yêu cầu tóm tắt 3 gạch đầu dòng trên cả GPT và Claude (bản miễn phí). So sánh chất lượng, độ chính xác với tiếng Việt. Ghi lại nhận xét.
Bài 4 — Tư duy compliance. Cho tình huống: ngân hàng muốn dùng LLM đọc hồ sơ vay có chứa CMND và thông tin lương khách hàng. Viết một đoạn ngắn (200 từ) lập luận nên dùng API ngoài hay Llama tự host, và liệt kê các biện pháp bảo vệ dữ liệu cần có.
Tóm tắt
LLM mở rộng biên giới của tự động hóa từ dữ liệu có cấu trúc sang dữ liệu phi cấu trúc — email, tài liệu, hội thoại — vốn trước đây nằm ngoài tầm với của RPA và workflow truyền thống. Hãy hình dung LLM như một "nhân viên ảo biết đọc viết" mà bạn gọi đến ở đúng bước cần hiểu ngôn ngữ.
Bốn use case kinh điển cần nhớ: email triage + soạn nháp, tóm tắt họp/tài liệu, trích xuất dữ liệu có cấu trúc từ văn bản tự do, và phân loại + định tuyến. Trong đó, trích xuất ra JSON là cây cầu giá trị nhất nối LLM với phần còn lại của workflow.
Ba dòng mô hình: GPT đa năng và hệ sinh thái rộng; Claude mạnh văn bản dài và tuân thủ chỉ dẫn; Llama open-weight cho phép tự host — lựa chọn sống còn với ngành nhạy cảm dữ liệu ở Việt Nam.
Và đừng quên ba nguyên tắc vận hành: luôn validate output, giữ con người ở vòng duyệt cuối với hành động rủi ro cao, và chọn đúng công cụ cho đúng việc (LLM cho ngôn ngữ, code cho logic). Làm chủ ba điều này, bạn đã sẵn sàng đưa LLM vào quy trình thật một cách an toàn và hiệu quả — và sẵn sàng bước sang Bài 26 về AI agent tự hành.