Xây dựng AI Workflow cho giáo viên Việt Nam: Những bài toán thực tế khi đưa LLM vào nghiệp vụ giáo dục

Làm một demo AI cho ngành giáo dục hiện nay không khó.

Mở ChatGPT, nhập:

"Hãy soạn cho tôi giáo án Toán 8 bài Phân thức đại số."

Vài giây sau, chúng ta có thể nhận được một bản giáo án khá đẹp mắt.

Nhưng nếu đưa ngay kết quả đó cho một giáo viên đang trực tiếp đứng lớp, chưa chắc họ sẽ sử dụng.

Lý do không nằm ở việc AI viết chưa hay.

Vấn đề là giáo viên không bắt đầu công việc từ một câu prompt trống.

Một kế hoạch bài dạy trong thực tế thường phụ thuộc vào nhiều yếu tố: bộ sách đang sử dụng, kế hoạch giáo dục của nhà trường, phân phối chương trình, yêu cầu cần đạt, cấu trúc hồ sơ chuyên môn và những yêu cầu tích hợp tương ứng với từng bối cảnh.

Điều đó dẫn đến một nhận xét khá quan trọng khi xây AI cho giáo dục:

Bài toán không phải là "AI có viết được giáo án hay không?", mà là "AI có thể tham gia vào đúng quy trình mà giáo viên đang làm việc hay không?"

Đây cũng là hướng mình theo đuổi khi xây dựng GiaoVienTot.

Thay vì xem LLM như một chatbot trả lời câu hỏi, mình xem nó như một thành phần bên trong một AI Workflow được thiết kế riêng cho nghiệp vụ.

---

1. Chatbot và AI Workflow là hai cách tiếp cận khác nhau

Một chatbot tổng quát thường có mô hình:

User
  ↓
Prompt
  ↓
LLM
  ↓
Response

Cách này rất hiệu quả với những tác vụ tương đối tự do như:

• viết nội dung;
• tóm tắt;
• brainstorm;
• giải thích;
• dịch thuật.

Nhưng với nghiệp vụ chuyên môn, đầu ra cần được ràng buộc bởi nhiều thứ hơn.

Ví dụ:

Dữ liệu người dùng
       +
Bối cảnh nghiệp vụ
       +
Quy tắc
       +
Cấu trúc đầu ra
       +
LLM
       ↓
Kết quả

Lúc này LLM không còn là toàn bộ sản phẩm.

Nó chỉ là một thành phần trong một hệ thống lớn hơn.

Đây là khác biệt mình thấy rõ nhất giữa một AI demo và một AI product.

---

2. Vấn đề lớn nhất không phải là model

Khi xây một AI application, rất dễ bị cuốn vào những câu hỏi như:

• Dùng model nào?
• Model nào thông minh hơn?
• Context window lớn đến đâu?
• Có nên dùng agent không?
• Có cần RAG không?

Những câu hỏi đó đều quan trọng.

Nhưng nếu dữ liệu đầu vào không đúng, workflow không rõ ràng và không có kiểm tra kết quả, model mạnh đến đâu cũng không giải quyết được hết bài toán.

Ví dụ một giáo viên có thể đưa vào hệ thống:

SGK
KHGD
PPCT
Tài liệu tham khảo

và mong muốn:

Giáo án

Nhưng giữa hai đầu đó là rất nhiều bước xử lý.

Hệ thống phải biết:

• tài liệu nào là nguồn chính;
• phần nào liên quan tới bài học;
• thông tin nào cần ưu tiên;
• phần nào cần giữ nguyên;
• phần nào có thể để AI đề xuất;
• kết quả cuối cùng sẽ được trình bày như thế nào.

Vì vậy, mình nhận ra rằng:

Muốn làm AI cho nghiệp vụ, phải thiết kế workflow trước rồi mới nghĩ tới prompt.

---

3. Cạm bẫy "Mega Prompt"

Một cách rất dễ mắc phải khi bắt đầu là viết một prompt ngày càng dài.

Ví dụ:

Bạn là chuyên gia giáo dục Việt Nam. Hãy đọc tài liệu A, đối chiếu tài liệu B, tuân thủ yêu cầu C, tạo tài liệu D, không được bỏ sót X, Y, Z...

Nếu kết quả chưa tốt, prompt lại tiếp tục được nối thêm.

Một thời gian sau, chúng ta có một "mega prompt" rất dài nhưng lại khó trả lời được câu hỏi:

Đoạn nào thực sự chịu trách nhiệm cho lỗi đang xảy ra?

Khi hệ thống lớn lên, cách tiếp cận hợp lý hơn là chia công việc thành các bước có trách nhiệm rõ ràng.

Có thể hình dung đơn giản:

Tài liệu
   ↓
Phân tích
   ↓
Chuẩn hóa
   ↓
Xây context
   ↓
AI xử lý
   ↓
Kiểm tra
   ↓
Người dùng xem và chỉnh sửa
   ↓
Xuất tài liệu

Điểm quan trọng ở đây không phải chính xác tên của từng module.

Điểm quan trọng là mỗi bước giải quyết một loại vấn đề khác nhau.

Đây cũng là lúc một nguyên tắc khá hữu ích xuất hiện:

Agentic khi cần, deterministic khi có thể.

Nếu một bước có thể kiểm soát chắc chắn bằng code, không nhất thiết phải giao toàn bộ quyết định cho AI.

---

4. Document AI: phần tưởng đơn giản nhưng thực tế không đơn giản

Một trong những việc đầu tiên mà AI cho giáo viên phải làm là đọc tài liệu.

Nghe có vẻ rất đơn giản.

Nhưng dữ liệu thực tế có thể đến từ:

DOCX
XLSX
PDF

và mỗi tài liệu lại có cách trình bày khác nhau.

Ví dụ hai bảng cùng chứa thông tin về kế hoạch giáo dục nhưng có thể:

• khác thứ tự cột;
• khác cách gộp ô;
• có nhiều dòng tiêu đề;
• có ghi chú;
• có phần thông tin nằm ngoài bảng.

Nếu chỉ lấy toàn bộ văn bản rồi đưa thẳng cho LLM, hệ thống đang bắt model làm quá nhiều việc cùng lúc:

Đọc
+
Hiểu cấu trúc
+
Tìm thông tin
+
Phân loại
+
Suy luận
+
Sinh nội dung

Một hướng tốt hơn là có lớp xử lý tài liệu ở trước AI.

Mục tiêu của lớp này là biến dữ liệu đầu vào thành một dạng dễ xử lý hơn.

Ví dụ về mặt khái niệm:

Tài liệu gốc
   ↓
Thông tin có cấu trúc
   ↓
Thông tin cần thiết
   ↓
AI

Không nhất thiết phải giữ mọi thứ trong context.

Context tốt không phải context dài nhất. Context tốt là context phù hợp với nhiệm vụ.

Đây là một trong những nguyên tắc mình thấy quan trọng khi phát triển công cụ soạn giáo án bằng AI của GiaoVienTot.

Thay vì bắt giáo viên phải tự viết một prompt dài, workflow bắt đầu từ tài liệu và thông tin bài dạy rồi mới xử lý nội dung.

---

5. Dữ liệu nghiệp vụ quan trọng không kém model

Trong AI application, đôi khi người ta quá chú ý đến LLM mà quên mất phần dữ liệu hỗ trợ.

Nhưng với nghiệp vụ giáo dục, một hệ thống chỉ thực sự hữu ích khi nó có đủ bối cảnh.

Ví dụ có thể cần biết:

Môn học
Khối lớp
Bài học
Số tiết
Yêu cầu cần đạt
Ngữ cảnh sử dụng

Ngoài ra còn có những dữ liệu mang tính quy chiếu mà hệ thống cần tham khảo.

Nếu không có lớp dữ liệu này, AI có xu hướng phải tự suy đoán.

Và khi AI phải suy đoán quá nhiều:

Hallucination ↑
Khả năng sai ↑
Khó kiểm soát ↑

Vì vậy, trong một sản phẩm AI chuyên ngành:

Knowledge Base và Master Data nhiều khi quan trọng không kém bản thân LLM.

---

6. Không nên để AI xuất dữ liệu tự do ở mọi nơi

Một vấn đề tiếp theo là output.

Nếu chỉ yêu cầu:

Hãy tạo giáo án.

thì model có thể trả về một đoạn văn dài.

Nhưng application cần phải:

Hiển thị trên web
        ↓
Cho phép chỉnh sửa
        ↓
Xuất Word

thì output tự do sẽ gây nhiều vấn đề.

Một cách tiếp cận tốt hơn là yêu cầu model tạo kết quả theo cấu trúc mà hệ thống đã định nghĩa trước.

Ví dụ ở mức khái niệm:

Mục tiêu
  ├─ Kiến thức
  ├─ Năng lực
  └─ Phẩm chất

Hoạt động
  ├─ Mục tiêu
  ├─ Nội dung
  ├─ Sản phẩm
  └─ Tổ chức thực hiện

Khi dữ liệu có cấu trúc, hệ thống có thể dễ dàng:

AI
 ↓
Structured Result
 ↓
UI
 ↓
DOCX

thay vì phải đoán xem đoạn text nào là tiêu đề, đoạn nào là hoạt động.

Đây là một trong những khác biệt giữa:

LLM tạo văn bản

và:

LLM cung cấp dữ liệu cho một application

---

7. LLM không nên là nguồn sự thật duy nhất

Đây có lẽ là bài học quan trọng nhất.

Model có thể viết rất tốt nhưng vẫn có thể:

• quên một trường;
• tạo dữ liệu không đúng;
• nhầm một giá trị;
• bỏ sót một thành phần;
• tạo hai phần không nhất quán.

Do đó sau bước generate nên có một lớp kiểm tra độc lập.

Ví dụ:

LLM
 ↓
Validation
 ↓
Đạt?
 ├── Có → tiếp tục
 └── Không → sửa / tạo lại / cảnh báo

Một số thứ hoàn toàn có thể kiểm tra bằng code thay vì AI.

Ví dụ:

Cấu trúc có đủ không?
Dữ liệu có đúng kiểu không?
Các thành phần có khớp nhau không?
Tổng điểm có hợp lệ không?

Tư duy này rất quan trọng:

Đừng bắt LLM chịu trách nhiệm cho những thứ mà code có thể kiểm tra chắc chắn hơn.

---

8. Tạo đề kiểm tra: nơi consistency trở thành bài toán lớn

Nếu chỉ tạo một câu hỏi, LLM có thể làm khá tốt.

Nhưng khi phải tạo cả một bộ đề thì vấn đề bắt đầu phức tạp hơn.

Một bộ đề có thể liên quan tới:

Ma trận
Bản đặc tả
Đề
Đáp án
Hướng dẫn chấm

Các thành phần này không tồn tại độc lập.

Một thay đổi ở phần này có thể ảnh hưởng tới phần khác.

Ví dụ:

Ma trận
→ phân bố nội dung

Bản đặc tả
→ mô tả yêu cầu

Đề
→ hiện thực hóa yêu cầu

Đáp án
→ phải khớp với đề

Nếu xem mỗi phần là một yêu cầu hoàn toàn độc lập đối với LLM, nguy cơ lệch thông tin sẽ tăng lên.

Một hướng tiếp cận tốt hơn là tạo một nguồn dữ liệu trung gian đại diện cho cấu trúc của bộ đề, sau đó dùng dữ liệu đó để sinh các phần liên quan.

Không cần phải để LLM tự "nhớ" mọi thứ qua nhiều lần gọi.

Đây là kiểu tư duy rất hữu ích khi xây các workflow AI có nhiều output phụ thuộc lẫn nhau.

Trong thực tế, đây cũng là bài toán mà workflow tạo đề kiểm tra của GiaoVienTot phải giải quyết: không chỉ tạo câu hỏi, mà còn phải giữ quan hệ giữa các thành phần của một bộ đề.

---

9. Generation khác Transformation

Có một loại bài toán còn thú vị hơn việc tạo tài liệu mới.

Đó là biến đổi tài liệu đã có.

Ví dụ:

"Tôi đã có KHGD rồi. Giữ nguyên bảng hiện tại và bổ sung thêm nội dung cần thiết."

Đây không phải là:

Generate

mà là:

Transform

Sự khác biệt rất quan trọng.

Nếu AI được giao viết lại toàn bộ tài liệu, những phần người dùng muốn giữ nguyên có thể bị thay đổi ngoài ý muốn.

Một hệ thống phù hợp hơn sẽ cố gắng xác định:

Cái gì cần giữ?
Cái gì cần thay?
Cái gì cần thêm?

rồi chỉ tác động vào đúng phần liên quan.

Đây là trải nghiệm đặc biệt quan trọng với những tài liệu mà người dùng đã đầu tư nhiều công sức chỉnh sửa.

Không phải lúc nào người dùng cũng muốn:

"AI làm lại cho tôi."

Nhiều khi họ chỉ muốn:

"AI giúp tôi làm nốt phần này."

Đó cũng là tinh thần của workflow tích hợp KHGD của GiaoVienTot: bắt đầu từ tài liệu có sẵn và hỗ trợ bổ sung phần thông tin còn thiếu thay vì mặc định viết lại tất cả.

---

10. AI Agent không phải lúc nào cũng cần "tự chủ"

Một xu hướng hiện nay là đưa chữ "Agent" vào gần như mọi sản phẩm AI.

Nhưng không phải workflow nào cũng cần một autonomous agent.

Nếu quy trình đã tương đối rõ:

Phân tích
→ Xử lý
→ Generate
→ Validate
→ Export

thì hoàn toàn có thể kiểm soát phần lớn flow bằng code.

LLM nên tập trung vào những việc mà nó thực sự mạnh:

Hiểu ngôn ngữ
Tổng hợp
Diễn đạt
Suy luận
Mapping ngữ nghĩa

Trong khi code phù hợp hơn cho:

Kiểm tra dữ liệu
Lưu trạng thái
Quản lý workflow
Kiểm tra cấu trúc
Xuất file

Điều này giúp hệ thống:

• dễ debug hơn;
• dễ kiểm thử hơn;
• dễ quan sát hơn;
• dễ thay đổi model hơn.

Nói cách khác, AI Agent không phải mục tiêu.

Workflow hiệu quả mới là mục tiêu.

---

11. Human-in-the-loop mới là mô hình thực tế

Một câu hỏi thường gặp là:

"Có thể tự động hóa 100% không?"

Về mặt demo, câu trả lời có thể nghe rất hấp dẫn.

Nhưng với nghiệp vụ chuyên môn, mình cho rằng mô hình thực tế hơn là:

AI
 ↓
Bản nháp
 ↓
Con người xem
 ↓
Chỉnh sửa
 ↓
Duyệt

AI rất phù hợp để:

• đọc tài liệu;
• tổng hợp;
• tạo bản nháp;
• gợi ý;
• phát hiện một số lỗi có thể kiểm tra tự động.

Con người vẫn nên quyết định:

• nội dung có phù hợp không;
• hoạt động có phù hợp với lớp học không;
• kết quả có cần chỉnh sửa không;
• có nên sử dụng chính thức không.

Điều này đặc biệt quan trọng trong giáo dục.

Mục tiêu không phải:

AI thay giáo viên.

Mà là:

AI giảm những phần việc lặp lại để giáo viên dành thời gian cho phần việc cần chuyên môn và phán đoán của con người.

---

12. Preview có thể quan trọng hơn tốc độ generate

Một AI application thường rất thích nói:

"Tạo kết quả trong vài giây."

Nhưng người dùng không phải lúc nào cũng cần nhanh nhất.

Với tài liệu chuyên môn, họ cần kiểm soát được kết quả.

Một UX hợp lý có thể là:

Generate
   ↓
Preview
   ↓
Edit
   ↓
Export

thay vì:

Generate
   ↓
Download
   ↓
Mở Word
   ↓
Sửa lại

Preview giúp người dùng nhìn thấy AI đã làm gì trước khi đưa kết quả ra khỏi hệ thống.

Nó cũng giúp giải quyết một vấn đề tâm lý quan trọng:

AI bớt giống một "hộp đen".

Người dùng có thể xem, sửa và quyết định.

---

13. Bài toán backend cũng thay đổi khi AI đi vào production

Ở giai đoạn prototype, developer thường có thể làm:

Request
 ↓
LLM
 ↓
Response

Nhưng với tài liệu lớn và workflow nhiều bước, thời gian xử lý tăng lên đáng kể.

Lúc này hệ thống thường phải quan tâm đến:

Job
Queue
Retry
Progress
Failure handling
History

Thay vì giữ người dùng trong một request duy nhất, hệ thống có thể xử lý theo job và cập nhật trạng thái.

Ví dụ về mặt UX:

Đang đọc tài liệu...
      ↓
Đang phân tích...
      ↓
Đang xử lý...
      ↓
Đang kiểm tra...
      ↓
Hoàn tất

Điều này không chỉ giải quyết vấn đề kỹ thuật.

Nó còn tạo ra cảm giác rằng hệ thống đang thực sự làm việc chứ không phải bị treo.

Đây là một trong những điểm khác biệt giữa một prototype AI và một sản phẩm SaaS có người dùng thật.

---

14. Một AI product tốt không nhất thiết phải có model mạnh nhất

Sau một thời gian làm AI application, có một điều ngày càng rõ:

Model chỉ là một phần của sản phẩm.

Một hệ thống có model rất mạnh nhưng:

Input sai
+
Context sai
+
Workflow rối
+
Output không ổn định
+
Không có validation
+
UX kém

vẫn có thể đem lại trải nghiệm tệ.

Trong khi một hệ thống được thiết kế tốt có thể tạo ra giá trị rất lớn nhờ:

Data
+
Workflow
+
Rules
+
LLM
+
Validation
+
UX

Đây mới là lớp tạo ra sự khác biệt.

Và cũng là lý do mình nghĩ cuộc cạnh tranh giữa các AI product trong tương lai sẽ không chỉ nằm ở:

"Ai dùng model tốt hơn?"

mà còn nằm ở:

"Ai hiểu workflow của người dùng sâu hơn?"

---

15. GiaoVienTot là một ví dụ của cách tiếp cận này

Trong quá trình xây dựng GiaoVienTot, mình không cố biến sản phẩm thành một chatbot biết mọi thứ.

Thay vào đó, các nhu cầu được tách thành những workflow cụ thể hơn:

• soạn giáo án;
• tích hợp KHGD;
• tạo câu hỏi;
• xây dựng ma trận, bản đặc tả và đề kiểm tra.

Trang bộ công cụ dành cho giáo viên cũng đi theo hướng đó: mỗi bài toán có ngữ cảnh, đầu vào và đầu ra riêng.

Ví dụ, thay vì yêu cầu người dùng tự nghĩ:

"Tôi phải viết prompt thế nào để AI hiểu tài liệu này?"

workflow có thể bắt đầu bằng:

Chọn công việc
     ↓
Cung cấp tài liệu
     ↓
AI xử lý
     ↓
Xem kết quả
     ↓
Chỉnh sửa
     ↓
Xuất tài liệu

Mục tiêu là đưa AI vào đúng công việc, thay vì bắt người dùng học cách "ra lệnh cho AI".

Đó là một thay đổi nhỏ trong UX nhưng lại rất lớn về mặt sản phẩm.

---

16. Điều khó copy không phải là một prompt

Khi chia sẻ về AI product, có một câu hỏi khá thú vị:

Nếu mình công khai cách tiếp cận thì người khác có copy được không?

Câu trả lời là: có thể copy ý tưởng, nhưng rất khó copy toàn bộ sản phẩm chỉ từ một bài viết.

Ví dụ, những thứ như:

LLM
RAG
Document Processing
Validation
Preview
Export

đều không phải bí mật.

Những thứ tạo ra lợi thế thực sự thường nằm sâu hơn:

Dữ liệu đã chuẩn hóa
Quy tắc nghiệp vụ
Các trường hợp ngoại lệ
Chất lượng mapping
Bộ kiểm thử
UX
Feedback người dùng
Các quyết định sản phẩm

Hai sản phẩm có thể cùng dùng một model nhưng cho kết quả rất khác nhau.

Vì vậy, khi xây AI SaaS, mình nghĩ không nên cố giữ bí mật mọi thứ.

Nên chia sẻ tư duy và bài học, nhưng không cần công khai toàn bộ implementation.

---

17. Một số nguyên tắc mình rút ra

Sau khi nhìn bài toán theo hướng system thay vì chatbot, có một số nguyên tắc khá đơn giản nhưng hữu ích.

1. Workflow trước, prompt sau

Đầu tiên phải biết người dùng muốn hoàn thành việc gì.

2. Context đúng quan trọng hơn context dài

Đưa đúng dữ liệu thường hữu ích hơn đưa thật nhiều dữ liệu.

3. Structured output tốt hơn freeform output

Nếu kết quả phải đi vào application, hãy thiết kế cấu trúc ngay từ đầu.

4. LLM không phải nguồn sự thật duy nhất

Những gì có thể kiểm tra bằng code thì nên kiểm tra bằng code.

5. Generate và Transform là hai bài toán khác nhau

Không phải lúc nào người dùng cũng muốn AI viết lại từ đầu.

6. Human-in-the-loop là tính năng, không phải hạn chế

Trong những nghiệp vụ có tính chuyên môn, con người vẫn cần là người quyết định cuối cùng.

7. Agent không phải mục tiêu

Một workflow rõ ràng và đáng tin cậy quan trọng hơn một agent "thông minh" nhưng khó kiểm soát.

---

18. Kết luận

Xây AI cho giáo viên không đơn giản là lấy một LLM rồi thêm một ô nhập prompt.

Bài toán thực tế gần hơn với:

Tài liệu
+
Dữ liệu nghiệp vụ
+
Workflow
+
LLM
+
Validation
+
Human Review
+
Output

LLM là phần rất quan trọng.

Nhưng nó chỉ là một phần.

Giá trị thực sự xuất hiện khi AI được đưa vào đúng quy trình:

Tài liệu đầu vào
      ↓
Hiểu bối cảnh
      ↓
Xử lý
      ↓
Kiểm tra
      ↓
Xem và chỉnh sửa
      ↓
Tạo tài liệu sử dụng được

Với giáo viên, mục tiêu cuối cùng không phải là tạo ra một câu trả lời "thông minh".

Mục tiêu là giúp họ hoàn thành một công việc thật nhanh hơn, với ít thao tác lặp lại hơn, nhưng vẫn giữ được quyền kiểm soát chuyên môn.

Đó cũng là hướng mình đang theo đuổi khi xây dựng GiaoVienTot.

Và có lẽ câu hỏi thú vị nhất khi xây một AI SaaS không phải:

"Model nào mạnh nhất?"

mà là:

"Mình hiểu công việc của người dùng sâu đến đâu?"

Bởi vì đến cuối cùng, người dùng không mua một mô hình ngôn ngữ.

Họ mua kết quả của công việc được hoàn thành tốt hơn.