Case study AI phải có móng vận hành

Case study AI phải có móng vận hành

Đừng đọc case study AI như bảng thành tích. Hãy đọc như hồ sơ quyết định: thử gì, đo gì, dừng khi nào, và lỗi nào sẽ cắn team bạn.

Có một kiểu họp rất quen ở team làm AI: ai đó mở slide, khoanh đỏ mấy con số đẹp, rồi cả phòng im lặng khoảng ba giây trước khi một người hỏi: vậy mình có nên làm giống họ không?

Câu trả lời khó chịu là: chưa chắc.

Case study AI không nên được đọc như bảng huy chương. Nó giống bản vẽ thi công hơn: cái đáng xem không chỉ là tòa nhà cao bao nhiêu, mà là họ đổ móng kiểu gì, chịu tải ra sao, chỗ nào phải gia cố, và khi nào nên ngừng xây thêm tầng.

Ba câu chuyện gần đây trên AWS cho mình một khung đọc khá thực dụng: Azercell huấn luyện model tiếng Azerbaijan trên SageMaker AI, Miro dùng Bedrock để route bug, Amazon Finance dùng generative AI cho regulatory inquiries. Ba bài toán khác nhau, nhưng cùng một điểm chung: giá trị thật nằm ở quyết định vận hành và hệ quả, không nằm ở việc có dùng model mới nhất hay không.

Sơ đồ minh họa cho bài Case study AI phải có móng vận hành

Sơ đồ tóm tắt ý chính của bài viết.

Ca Azercell: khi tokenizer mới là nền móng

Azercell muốn xây LLM tiếng Azerbaijan cho use case viễn thông và chatbot khách hàng. Nghe qua thì nhiều team sẽ nhảy ngay vào câu hỏi: chọn foundation model nào, GPU nào, fine-tune bao lâu?

Nhưng điểm đáng học lại nằm trước đó: tokenizer.

Tokenizer là lớp cắt chữ thành token để model xử lý. Với tiếng Anh, nhiều tokenizer phổ biến đã được tối ưu khá ổn. Nhưng với ngôn ngữ giàu hình thái như Azerbaijan, một từ có thể mang nhiều biến thể ngữ pháp. Nếu tokenizer cắt quá vụn, context window — vùng ngữ cảnh model còn giữ được trong một lượt xử lý — bị lãng phí như nhà chưa xây đã hụt vật liệu.

Trong case này, nhóm thử ba hướng: dùng tokenizer tối ưu cho tiếng Anh làm baseline, mở rộng vocabulary, và xây tokenizer đơn ngữ tùy biến. Kết quả được nêu khá rõ: tokenizer đơn ngữ giảm một nửa số token trên mỗi từ so với baseline, tức cải thiện khoảng 2× lượng chữ Azerbaijan nhét vừa vào context window.

Đây không phải chi tiết phụ. Với low-resource language — ngôn ngữ ít dữ liệu huấn luyện — mỗi token đều đắt. Nếu bạn bỏ qua tokenizer, bạn có thể đang trả tiền GPU để model học cách chịu đựng một cách cắt chữ tệ.

Phần continued pre-training, tức tiếp tục train một foundation model trên dữ liệu miền/ngôn ngữ mới, được thực hiện với Llama 3.2 1B, distributed training và Liger Kernels. Liger Kernels là tối ưu cấp kernel, nghĩa là can thiệp vào các phép tính thấp hơn để tăng throughput và giảm memory. Trên instance ml.p5.48xlarge, framework đạt throughput training cao hơn 23% và giảm peak GPU memory 58%.

Con số đẹp, nhưng bài học không phải là hãy dùng đúng stack đó. Bài học là: trước khi scale training, hãy đo xem phần móng ngôn ngữ có đang làm bạn tốn tiền vô ích không.

Ca Miro: bug routing không phải chatbot có thêm nhãn

Miro gặp một bài toán rất đời: bug report lộn xộn, thiếu context, có stack trace, ảnh, video, rồi phải route về gần 100 team. Nếu route sai, bug bị đá qua đá lại, developer mất thời gian điều tra lại từ đầu.

Ở đây, AI không đóng vai người trả lời cho vui. Nó là lớp triage trong workflow. Triage nghĩa là phân loại ưu tiên và hướng xử lý ban đầu, giống lúc bạn vào phòng khám và được hỏi triệu chứng trước khi gặp bác sĩ chuyên khoa.

Miro xây BugManager trên Amazon Bedrock để tự động route bug. Kết quả được công bố: số lần reassign giữa team giảm 6 lần và time-to-resolution rút từ ngày xuống giờ, cụ thể là ngắn hơn 5 lần. Nguồn cũng nêu vấn đề misrouting tạo ra 42 năm năng suất cộng dồn bị mất mỗi năm.

Nhưng nếu chỉ nhìn con số rồi về bảo team mình làm bug bot, bạn dễ trượt.

Điểm vận hành quan trọng là bug routing là multi-class classification — phân loại vào nhiều nhãn, trong trường hợp này là nhiều team phụ trách khác nhau. Bài toán này khác với chatbot hỏi đáp. Nó cần taxonomy team rõ, dữ liệu bug lịch sử đủ sạch, và vòng phản hồi khi route sai.

Hình dung thế này: nếu sơ đồ ownership trong công ty bạn đã lẫn lộn, AI chỉ làm cái lẫn lộn đó chạy nhanh hơn. Một tầng giàn giáo đẹp không cứu được khung kèo đang lệch.

Với team Việt Nam, đặc biệt team product 10-50 người, bài học thực tế là đừng bắt đầu bằng toàn bộ issue tracker. Hãy chọn một lát cắt hẹp: ví dụ chỉ bug mobile app, chỉ production incident, hoặc chỉ module billing. Đo ba thứ trước:

Nếu ba số này không nhúc nhích, đổi model chưa chắc giúp. Có thể bạn cần sửa nhãn, sửa mô tả component, hoặc ép bug template rõ hơn.

Ca Amazon Finance: AI trong compliance cần dấu vết, không cần múa đẹp

Amazon Finance xử lý regulatory inquiries, tức yêu cầu từ cơ quan quản lý ở nhiều jurisdiction khác nhau. Đây là dạng workflow vừa nhiều tài liệu, vừa nhiều bước, vừa không được phép trả lời sai kiểu tự tin quá mức.

Nguồn mô tả các thách thức chính: tài liệu nằm ở nhiều định dạng như PDF, PPT, Word, CSV; thuật ngữ domain-specific; cần giữ conversational state — trạng thái hội thoại qua nhiều lượt; và cần observability, tức khả năng quan sát vì sao hệ thống tạo ra câu trả lời như vậy.

Nói thẳng ra thì: trong compliance, câu trả lời đúng chưa đủ. Bạn còn phải biết nó dựa vào đâu.

Điểm đáng học là mỗi team duy trì knowledge base riêng. Knowledge base là kho tài liệu có cấu trúc để hệ thống truy xuất khi trả lời. Điều này nghe nhỏ, nhưng là quyết định vận hành lớn: thay vì có một kho tri thức khổng lồ rồi hy vọng retrieval tự chọn đúng, mỗi nhóm giữ phạm vi tài liệu của mình.

Với builder, đây là tradeoff rất thật:

| Lựa chọn | Lợi ích | Rủi ro |
|---|---|---|
| Một knowledge base chung | Dễ triển khai ban đầu, ít pipeline | Nhiễu domain, khó phân quyền, khó debug retrieval |
| Knowledge base theo team | Rõ ownership, dễ audit, ít lẫn ngữ cảnh | Tốn công chuẩn hóa, cần quy trình cập nhật |
| Hybrid | Linh hoạt cho tài liệu chung và riêng | Phức tạp hơn ở routing và permission |

Nếu hệ thống của bạn dính tới pháp lý, tài chính, y tế, bảo hiểm, hoặc dữ liệu nội bộ nhạy cảm, hãy ưu tiên khả năng truy vết hơn demo hội thoại mượt. Một câu trả lời không có citation đáng tin giống trần nhà đẹp nhưng không biết có dầm chịu lực ở đâu.

Khung đọc case study cho builder: thử nhỏ, đo thật, dừng sớm

Thay vì hỏi họ dùng dịch vụ gì, mình sẽ đọc mỗi case study bằng năm câu hỏi này:

1. Bottleneck thật nằm ở đâu?

Azercell không chỉ thiếu model tiếng Azerbaijan; họ bị chi phí token và dữ liệu hạn chế bóp cổ. Miro không chỉ thiếu chatbot; họ bị bug reassign làm chậm SLA. Amazon Finance không chỉ thiếu tìm kiếm; họ cần retrieval có dấu vết và context qua nhiều lượt.

Nếu bạn chưa chỉ ra bottleneck, mọi lựa chọn tool đều hơi sớm.

2. Artifact nào được tạo ra sau mỗi bước?

Artifact là đầu ra có thể dùng lại: tokenizer, dataset đã lọc, benchmark nội bộ, routing labels, knowledge base, audit log. Case study tốt luôn để lại artifact, không chỉ để lại cảm giác hào hứng.

3. Metric nào nối trực tiếp với vận hành?

Training throughput và peak GPU memory có ý nghĩa vì chúng ảnh hưởng chi phí huấn luyện. Tokens per word có ý nghĩa vì nó ảnh hưởng context. Reassignment count có ý nghĩa vì nó chạm vào thời gian developer. Observability có ý nghĩa vì nó quyết định bạn có dám đưa hệ thống vào workflow nhạy cảm không.

Metric đẹp nhưng không đổi hành vi vận hành thì chỉ là trang trí.

4. Failure mode nào phải chặn trước?

Với tokenizer: model xử lý tiếng bản địa kém vì tokenization vụn.

Với bug routing: ownership taxonomy sai làm AI route sai hàng loạt.

Với regulatory inquiries: retrieval nhầm tài liệu nhưng câu trả lời vẫn nghe rất tự tin, đây là hallucination — bịa thông tin nhưng trình bày như thật.

5. Tiêu chí dừng là gì?

Đây là câu bị bỏ quên nhiều nhất. Một thử nghiệm AI nên có điều kiện dừng rõ:

Không có tiêu chí dừng, pilot rất dễ thành công trình dang dở: cứ thêm tầng, thêm phòng, thêm ngân sách, nhưng không ai dám nghiệm thu.

Một buổi thử cho team của bạn

Nếu bạn đang làm tech lead và muốn áp dụng tinh thần này trong một buổi chiều, đừng clone toàn bộ kiến trúc của ai cả. Làm một bản thử có kiểm soát:

  1. Chọn một workflow đau nhất: bug routing, support ticket, tra cứu policy, hoặc xử lý tài liệu nội bộ. Chỉ chọn một.
  2. Lấy 50-100 mẫu lịch sử: đủ để thấy pattern, chưa cần làm dataset hoành tráng. Nếu dùng số này, xem nó như ví dụ minh họa cho pilot nhỏ, không phải chuẩn phổ quát.
  3. Viết baseline thủ công: con người hiện xử lý mất bao lâu, sai ở đâu, chuyển tay mấy lần.
  4. Chạy một phương án AI đơn giản: có thể là classification, RAG — retrieval-augmented generation, tức trả lời dựa trên tài liệu truy xuất — hoặc tokenizer evaluation nếu bạn làm ngôn ngữ riêng.
  5. Đặt ngưỡng scale/dừng: ví dụ phải giảm rõ rệt chuyển tay, giữ citation đúng, hoặc giảm token cost trước khi thêm dữ liệu và hạ tầng.

Điều bạn sẽ nghĩ khác sau bài này: case study không phải lời mời bắt chước stack, mà là bài kiểm tra xem team kia đã ra quyết định vận hành thế nào.

Nếu là mình, mình sẽ bắt đầu từ chỗ ít hào nhoáng nhất: đo tokenization, đo reassignment, đo retrieval trace. Vì hệ thống AI production không sập ở slide demo; nó sập ở những khe nứt nhỏ mà lúc xây móng mình lười kiểm tra.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo