Nếu bạn từng phải chấm công sau một ngày làm việc dài, bạn sẽ hiểu cảm giác đó: nhìn chằm chằm vào form, cố nhớ lại mình đã làm gì, trong bao lâu, và thuộc dự án nào. Rất tẻ nhạt — và đây chính xác là loại công việc mà AI có thể làm thay cho bạn.
Bài viết này đi qua kiến trúc thực tế mà nhóm chúng tôi thiết kế để giải quyết vấn đề đó: một công cụ chấm công hỗ trợ AI xây trên nền hệ thống ETM (Employee Time Management) hiện có. Không có gì phức tạp — chỉ là một pipeline rõ ràng mà bạn có thể theo từng bước.
Bức tranh tổng thể
Hãy hình dung hệ thống như một trợ lý thông minh đứng giữa bạn và form chấm công. Thay vì điền tay từng ô, bạn chỉ cần nói chuyện với nó — hoặc gõ tự nhiên — và nó tự xử lý phần còn lại.
Đây là những gì xảy ra bên trong:
- Bạn gửi tin nhắn thoại hoặc văn bản từ điện thoại hay trình duyệt.
- API Gateway (xây bằng NestJS) nhận yêu cầu.
- AI Orchestrator tiếp quản — điều phối nhiều module chuyên biệt để hiểu input của bạn.
- Nếu input đầy đủ, hệ thống tự log entry chấm công.
- Nếu thiếu thông tin, hệ thống hỏi lại — như một cuộc hội thoại chat thông thường.
Bước 1 — Input của bạn vào hệ thống
Client (web hoặc mobile) nhận hai loại input:
- Văn bản: "Tôi làm fix bug dashboard ETM 3 tiếng sáng nay, project ETM-2024."
- Giọng nói: Bạn nói, module Speech-to-Text (STT) chuyển thành text.
Dù theo cách nào, tất cả đều trở thành text trước khi AI bắt đầu xử lý. Điều này giữ cho phần còn lại của pipeline đơn giản và nhất quán.
Bước 2 — LLM phân tích ý định của bạn
Khi text đến AI Orchestrator, một Large Language Model (LLM) đọc và cố gắng trích xuất một entry chấm công có cấu trúc. Hãy nghĩ đây như việc tự động điền form:
{
"project": "ETM-2024",
"task": "Fix bug dashboard",
"duration_hours": 3,
"date": "2025-04-17",
"time_of_day": "morning"
}LLM được prompt để trả về JSON, không phải văn bản tự do. Đây gọi là structured output — kỹ thuật phổ biến khi bạn nói với model chính xác dạng dữ liệu bạn cần.
Bước 3 — RAG điền ngữ cảnh bạn chưa nhắc đến
Nếu bạn chỉ nói "làm fix bug" mà không nêu project thì sao? Đó là lúc tầng RAG (Retrieval-Augmented Generation) phát huy tác dụng.
RAG kết nối LLM với một vector database lưu lịch sử project, phân công nhóm, và hoạt động gần đây của bạn. Nếu "fix bug" liên tục xuất hiện cùng "ETM-2024" trong 10 entry gần nhất, hệ thống có thể suy luận và tự điền vào.
Tương tự như cách ứng dụng email gợi ý hoàn thành câu dựa trên lịch sử viết của bạn, nhưng thông minh hơn vì nó suy luận trên dữ liệu có cấu trúc.
Bước 4 — Validation phát hiện thông tin còn thiếu
Module Validator kiểm tra entry đã parse so với các field bắt buộc. Một entry chấm công hợp lệ thường cần:
- Mã project
- Mô tả công việc
- Số giờ
- Ngày
Nếu vẫn còn thiếu sau bước LLM và RAG, hệ thống không im lặng bỏ qua. Nó kích hoạt một vòng hội thoại.
Bước 5 — Chatbot hỏi, bạn trả lời
Đây là phần thú vị nhất. Thay vì trả về lỗi, trợ lý gửi cho bạn một câu hỏi thân thiện:
"Được rồi — 3 tiếng fix bug dashboard. Bạn muốn log vào project nào?"
Bạn trả lời: "ETM-2024."
Hệ thống merge câu trả lời với dữ liệu hiện có và validate lại. Nếu đủ, nó tiếp tục. Nếu không, hỏi thêm — cho đến khi entry hoàn chỉnh. Vòng lặp này nhẹ và nhanh vì LLM chỉ cần parse một câu trả lời ngắn mỗi lần.
Bước 6 — Entry được submit
Khi entry đã được validate đầy đủ, Action Router gửi nó đến API phù hợp — Timesheet API hoặc Leave API tùy loại entry. Các API ghi dữ liệu vào SQL database, giống hệt một form submit bình thường. Tầng AI hoàn toàn trong suốt với backend.
Tại sao kiến trúc này phù hợp với team
Một vài điểm khiến cách tiếp cận này thực tế cho doanh nghiệp:
- Không cần thay đổi backend. Tầng AI nằm trên các API hiện có. ETM không biết và không cần biết AI đã submit timesheet.
- Xuống cấp nhẹ nhàng. Nếu LLM không khả dụng, hệ thống fallback về form thông thường. AI là cải tiến, không phải dependency.
- Có thể kiểm tra. Mỗi bước đều được log — người dùng nói gì, LLM parse ra gì, gì đã được submit. Bạn có thể trace bất kỳ entry nào về nguồn gốc.
- Dễ mở rộng. Pattern tương tự áp dụng được cho đơn nghỉ phép, khai báo chi phí, hay bất kỳ form cấu trúc nào mà người dùng thấy nhập tay phiền.
Tổng kết
Cốt lõi rất đơn giản: người dùng không nên phải nghĩ theo schema của database. Họ nên có thể nói điều họ đã làm bằng ngôn ngữ tự nhiên, và hệ thống tự xử lý phần còn lại — chỉ hỏi khi thực sự không biết.
Đây là hình ảnh của AI tooling tốt trong bối cảnh doanh nghiệp thực tế: không phải chatbot gắn thêm vào, mà là một tầng nói được ngôn ngữ của người dùng lẫn ngôn ngữ của hệ thống cùng một lúc.
Nếu bạn đang xây dựng thứ gì đó tương tự, stack khá đơn giản — NestJS cho gateway, bất kỳ LLM lớn nào hỗ trợ function calling hoặc structured output, vector store như pgvector hoặc Qdrant cho RAG, và các REST API hiện có ở backend. Phần khó không phải công nghệ — mà là thiết kế validation logic và các prompt hội thoại sao cho chúng cảm giác tự nhiên, không máy móc.