1. Mục tiêu khi đưa AI vào HRM

Với hệ thống HRM lớn, AI không nên triển khai kiểu “cho đẹp”, mà phải phục vụ đúng bài toán vận hành. Nên chia làm 4 nhóm use case:

Nhóm 1: AI hỗ trợ nghiệp vụ HR

• Gợi ý trả lời ticket / câu hỏi nội bộ
• Tóm tắt đơn từ, lịch sử trao đổi, ghi chú nhân sự
• Gợi ý phân loại yêu cầu HR

Nhóm 2: AI phân tích dữ liệu nhân sự

• Phát hiện bất thường chấm công / OT / nghỉ phép
• Dự báo nghỉ việc
• Dự báo thiếu hụt nhân sự theo phòng ban

Nhóm 3: AI cho tuyển dụng

• Matching CV với job
• Tóm tắt hồ sơ ứng viên
• Ranking candidate

Nhóm 4: AI cho self-service

• Chatbot nội bộ cho nhân viên:
  • tra cứu policy
  • tra cứu quy trình
  • giải thích đơn nghỉ phép / công / lương

2. Nguyên tắc kiến trúc cho hệ thống 7000 user

Với quy mô 7000 user, nguyên tắc quan trọng nhất là:

2.1. AI không được nằm trực tiếp trong request chính

Không để:

• form open
• onchange
• create/write
• approve action

gọi AI trực tiếp.

Vì sẽ gây:

• chậm giao diện
• timeout
• tăng tải worker Odoo
• khó kiểm soát lỗi provider AI

👉 AI chỉ nên chạy theo 3 kiểu:

• async job
• cron batch
• background compute theo event

2.2. AI là lớp phụ trợ, không phải source of truth

Source of truth vẫn là:

• dữ liệu HRM trong Odoo
• rule nghiệp vụ
• workflow approval hiện có

AI chỉ:

• gợi ý
• chấm điểm
• cảnh báo
• tóm tắt

Không để AI:

• tự approve lương
• tự approve nghỉ phép
• tự chốt điều chuyển
• tự sửa dữ liệu nhân sự quan trọng

2.3. Tách riêng AI service layer

Không gọi provider AI rải rác trong module HR, payroll, attendance.

Phải có 1 lớp trung gian chuẩn hóa:

• prompt builder
• retry
• timeout
• logging
• cache
• security masking

3. Kiến trúc tổng thể đề xuất

3.1. High-level architecture

[User/UI Odoo]

   |

   v

[HRM Modules]

(hr.employee, attendance, leave, payroll, recruitment, helpdesk)

   |

   v

[AI Orchestrator Layer]

   – AI Gateway

   – Prompt Builder

   – Policy / Masking

   – Queue Dispatcher

   – Result Parser

   – Cache

   |

   +———————+

   |                     |

   v                     v

[LLM Provider]       [ML / Rule Engine]

(OpenAI/Azure/local) (anomaly, scoring, forecast)

   |

   v

[AI Result Storage]

   – ai.job

   – ai.result

   – ai.audit.log

   – score fields on business models

3.2. Các thành phần chính

A. Odoo business modules

Ví dụ:

• hr.employee
• hr.attendance
• hr.leave
• hr.contract
• hr.payslip
• hr.applicant
• helpdesk.ticket hoặc module nội bộ hỏi đáp HR

Đây là nơi phát sinh event nghiệp vụ.

B. AI Gateway module

Tạo 1 module nền kiểu:

• vti_ai_base
• hoặc hr_ai_core

Module này chịu trách nhiệm:

• kết nối provider AI
• timeout
• retry
• log request/response
• routing model
• cost tracking

Ví dụ abstract service:

from odoo import models, api

import logging

_logger = logging.getLogger(__name__)

 

class AiGateway(models.AbstractModel):

   _name = ‘ai.gateway’

   _description = ‘AI Gateway’

 

   def call_llm(self, task_type, payload, config=None):

       config = config or {}

       provider = self._get_provider(task_type)

       prompt = self._build_prompt(task_type, payload)

       prompt = self._mask_sensitive_data(prompt)

 

       try:

           result = provider.execute(prompt, config=config)

           self._log_success(task_type, payload, result)

           return result

       except Exception as e:

           self._log_error(task_type, payload, e)

           return False

C. Queue / async processing

Khuyến nghị:

• dùng cron + bảng queue riêng
• hoặc queue_job nếu hệ thống đang dùng tốt
• hoặc job table custom nếu muốn kiểm soát sâu

Ví dụ model queue:

• ai.job
• ai.result

ai.job lưu:

• model
• record_id
• task_type
• payload
• priority
• state
• retry_count
• requested_by
• started_at
• finished_at
• error_message

D. Rule Engine / ML Engine

Không phải bài nào cũng cần LLM.

Nên tách 2 hướng:

LLM use case

Phù hợp cho:

• tóm tắt
• chatbot
• generate nội dung
• giải thích policy
• CV summary

Rule / ML use case

Phù hợp cho:

• anomaly attendance
• OT abnormal detection
• attrition scoring
• leave abuse detection
• candidate ranking theo structured data

Tức là:

• cái gì có cấu trúc rõ, nên dùng rule/ML trước
• cái gì là ngôn ngữ tự nhiên, mới dùng LLM

4. Kiến trúc dữ liệu đề xuất

4.1. Model nền cho AI

ai.job

Quản lý hàng đợi AI

Field gợi ý:

• name
• task_type
• model_name
• record_id
• payload_json
• state (draft, queued, processing, done, failed)
• priority
• retry_count
• requested_by
• result_id
• error_message
• started_at
• finished_at

ai.result

Lưu kết quả AI

Field gợi ý:

• job_id
• task_type
• model_name
• record_id
• response_text
• response_json
• score
• confidence
• provider
• token_usage
• cost_estimate
• approved_by_user
• is_applied

ai.audit.log

Lưu audit để debug và compliance

Field gợi ý:

• job_id
• request_summary
• masked_fields
• provider_status
• latency_ms
• error_trace

4.2. Gắn score vào model nghiệp vụ

Ví dụ:

hr.employee

• ai_attrition_score
• ai_attrition_note
• ai_last_analyzed_at

hr.attendance

• ai_anomaly_score
• ai_anomaly_reason
• ai_review_state

hr.applicant

• ai_match_score
• ai_resume_summary
• ai_rank

hr.leave

• ai_risk_flag
• ai_risk_note

5. Các use case quan trọng cho HRM 7000 user

5.1. Attendance anomaly detection

Mục tiêu

Phát hiện:

• check-in/out bất thường
• OT bất thường
• chấm công lệch pattern
• nhân viên có xu hướng vi phạm

Flow đề xuất

attendance imported / synced

   ->

rule engine check

   ->

if suspicious -> create ai.job

   ->

AI summarize abnormal pattern

   ->

show to HR approver

Tại sao phải rule trước, AI sau

Vì 7000 user tạo rất nhiều log chấm công. Nếu record nào cũng gọi AI thì quá nặng.

Nên pipeline là:

Bước 1: filter bằng SQL/rule

Ví dụ:

• đi muộn > 3 lần / tuần
• OT > 40h / tháng
• check-in ngoài khung giờ thường
• device/location mismatch

Bước 2: chỉ record nghi ngờ mới tạo AI job

AI sẽ:

• tóm tắt pattern
• giải thích mức độ rủi ro
• gợi ý cần HR review hay không

5.2. Leave request risk scoring

Mục tiêu

Khi nhân viên tạo đơn nghỉ:

• không dùng AI để approve
• chỉ đánh dấu risk

Risk factors

• nghỉ sát ngày
• nghỉ trùng nhiều người cùng team
• lịch sử nghỉ bất thường
• nghỉ nhiều quanh ngày lễ
• nhân viên đang ở giai đoạn critical project

Kiến trúc

• rule engine tính base score
• AI chỉ tạo summary cho manager/HR

Ví dụ note:

• “Nhân viên đã có 4 đơn nghỉ đột xuất trong 60 ngày gần nhất”
• “Bộ phận hiện có 3 người nghỉ cùng ngày”
• “Nghỉ vào giai đoạn chốt payroll”

5.3. Attrition prediction

Mục tiêu

Dự báo nhân viên có nguy cơ nghỉ việc.

Nguồn dữ liệu

• attendance trend
• OT trend
• leave pattern
• performance history
• internal transfer
• manager change
• compensation movement
• survey / feedback nếu có

Kiến trúc phù hợp

Bài này không nên dùng LLM làm lõi.
Nên dùng:

• rule-based scoring trước
• sau đó nếu cần thì ML model riêng
• LLM chỉ để giải thích score thành ngôn ngữ dễ hiểu

Ví dụ:

• ML output: 0.78
• LLM chuyển thành:
  • “Nguy cơ nghỉ việc ở mức cao do OT kéo dài, tần suất nghỉ đột xuất tăng và thay đổi quản lý gần đây.”

5.4. Recruitment AI

Chức năng nên có

• CV parsing
• CV summary
• Job matching
• candidate ranking
• question suggestion cho interviewer

Pipeline

CV upload

 ->

extract text

 ->

structured parsing

 ->

match with job requirement

 ->

store score + summary

 ->

recruiter review

Gợi ý kỹ thuật

• text extraction tách riêng khỏi LLM
• match score nên có rule + keyword + embedding, không chỉ prompt text đơn thuần
• summary có thể dùng LLM

5.5. HR chatbot nội bộ

Mục tiêu

Cho nhân viên hỏi:

• còn bao nhiêu phép
• quy định OT là gì
• nghỉ cưới được mấy ngày
• khi nào nhận lương
• hồ sơ bảo hiểm cần gì

Kiến trúc chuẩn

Không để chatbot chỉ gọi LLM “hỏi gì trả lời nấy”.

Phải theo kiểu RAG nội bộ:

User question

  ->

Intent detection

  ->

If structured data question:

   query Odoo directly

If policy question:

   retrieve docs / knowledge base

  ->

LLM generate answer from retrieved context

Ví dụ

Câu hỏi structured

“Tôi còn bao nhiêu ngày phép?”

• không cần LLM
• query trực tiếp Odoo

Câu hỏi policy

“Nghỉ thai sản cần hồ sơ gì?”

• retrieve policy doc
• LLM chỉ rephrase / summarize

6. Phân lớp kỹ thuật chi tiết

6.1. Layer 1 – Trigger layer

Phát sinh từ:

• cron
• button action
• create/write event
• import/sync complete
• user manual request

Nhưng trigger chỉ nên tạo job, không gọi AI ngay.

Ví dụ:

def action_queue_ai_analysis(self):

   for rec in self:

       self.env[‘ai.job’].create({

           ‘task_type’: ‘attendance_anomaly’,

           ‘model_name’: rec._name,

           ‘record_id’: rec.id,

           ‘payload_json’: rec._prepare_ai_payload(),

           ‘state’: ‘queued’,

           ‘priority’: 50,

       })

6.2. Layer 2 – Dispatcher layer

Cron xử lý queue theo batch nhỏ.

Ví dụ:

• mỗi 1 phút lấy 20 job
• chia theo priority
• lock record để tránh double process

6.3. Layer 3 – AI execution layer

Chịu trách nhiệm:

• build prompt
• gọi provider
• parse response
• validate output schema

Không được write business data ngay nếu chưa qua validation.

6.4. Layer 4 – Result application layer

Chỉ apply những field an toàn:

• summary
• score
• flag
• suggested_action

Các field nhạy cảm:

• lương
• trạng thái hợp đồng
• trạng thái đơn phê duyệt

thì chỉ để user xác nhận.

7. Thiết kế hạ tầng để không làm chậm Odoo

7.1. Tách Odoo worker và AI worker

Nếu AI job chạy chung worker web:

• user mở form sẽ chậm
• approve payroll dễ lag

Nên tách:

Web workers

Phục vụ người dùng

Background workers

Phục vụ:

• cron AI
• queue AI
• batch scoring

7.2. Không xử lý real-time cho mọi thứ

Với 7000 user:

Nên near real-time

• chatbot
• generate summary theo nút bấm
• candidate summary

Nên batch

• attrition score
• attendance anomaly daily
• leave risk nightly
• OT trend weekly

7.3. Cache kết quả

Ví dụ:

• policy answer
• candidate summary
• employee risk summary

Không nên hỏi lại AI nếu dữ liệu gốc chưa đổi.

Cần có cache key kiểu:

• task_type
• model
• record_id
• version_hash

8. Bảo mật dữ liệu

HRM là vùng cực nhạy cảm.

8.1. Không gửi raw dữ liệu nhạy cảm lên external LLM

Cần mask:

• lương thực nhận
• số tài khoản
• CCCD
• địa chỉ
• số điện thoại
• thông tin y tế
• đánh giá nhạy cảm

8.2. Phân loại dữ liệu trước khi gửi AI

Có thể gửi

• policy text
• JD
• CV đã được consent
• attendance pattern đã ẩn danh một phần
• leave trend dạng tổng hợp

Không nên gửi

• payroll detail đầy đủ
• personal document scan
• disciplinary record nguyên bản
• dữ liệu bảo hiểm chi tiết

8.3. Phân quyền xem kết quả AI

Ví dụ:

• line manager chỉ xem summary thuộc team mình
• HRBP xem score theo phòng ban phụ trách
• HR admin xem full AI log
• end user không xem nội dung risk scoring nội bộ

9. Monitoring và vận hành

9.1. Dashboard cần có

Cho admin / dev:

• số AI job theo trạng thái
• latency trung bình
• fail rate
• token usage
• cost theo ngày
• top task type
• cache hit rate

9.2. Cảnh báo

Cần alert khi:

• fail rate tăng cao
• queue backlog lớn
• provider timeout
• cost vượt ngưỡng
• cron bị treo

10. Kiến trúc module Odoo đề xuất

Có thể tách thành các module sau:

hr_ai_core

Module nền:

• gateway
• queue
• result
• audit
• provider config

hr_ai_attendance

• anomaly detection
• attendance summary
• OT risk summary

hr_ai_leave

• leave risk score
• leave trend analysis

hr_ai_recruitment

• CV summary
• job matching
• interview question suggestion

hr_ai_chatbot

• employee self-service chatbot
• policy RAG
• structured HR query router

hr_ai_retention

• attrition score
• retention summary
• churn trend dashboard

11. Kiến trúc theo giai đoạn triển khai

Giai đoạn 1: low-risk, high-value

Nên làm trước:

• HR chatbot policy
• CV summary
• candidate matching
• attendance anomaly summary
• leave risk flag

Vì:

• dễ thấy hiệu quả
• ít rủi ro nghiệp vụ
• không can thiệp trực tiếp approval

Giai đoạn 2: analytics

• attrition scoring
• manpower forecast
• OT trend prediction
• department risk dashboard

Giai đoạn 3: advanced workflow assist

• manager recommendation
• auto-draft HR response
• smart case routing
• internal knowledge assistant

12. Đề xuất luồng kỹ thuật thực tế cho hệ thống

Nếu áp vào HRM factory 7000 nhân sự, mình sẽ khuyến nghị như sau:

Ưu tiên 1: Attendance + OT anomaly

Vì dữ liệu lớn, có giá trị vận hành cao, dễ thấy bất thường.

Ưu tiên 2: Recruitment AI

Vì tác động trực tiếp tới thời gian xử lý tuyển dụng.

Ưu tiên 3: HR policy chatbot

Giảm tải HR support.

Ưu tiên 4: Attrition dashboard

Dành cho HRBP / manager cấp cao.

13. Mẫu flow cụ thể: Attendance anomaly

[Device/Import/Cron sync attendance]

   ->

[Rule engine filter suspicious records]

   ->

[Create ai.job]

   ->

[Background worker calls AI]

   ->

[Store ai.result]

   ->

[Write score + summary to hr.attendance]

   ->

[HR dashboard shows abnormal cases]

   ->

[HR confirms / dismisses]

14. Mẫu flow cụ thể: HR chatbot

[Employee asks question]

   ->

[Intent router]

   -> structured data ? -> query Odoo

   -> policy question ? -> retrieve policy docs

   ->

[LLM answer builder]

   ->

[Return answer + source reference]

15. Kết luận

Với hệ thống HRM 7000 user, kiến trúc AI tốt không nằm ở chỗ “gọi được AI”, mà ở chỗ:

• không làm chậm Odoo
• không phá workflow hiện tại
• không đẩy dữ liệu nhạy cảm ra ngoài bừa bãi
• chỉ dùng AI ở nơi thực sự tạo giá trị
• luôn có lớp rule + review của con người

Nếu làm đúng, AI trong HRM sẽ hữu ích nhất ở 3 vai trò:

• assistant
• analyzer
• warning engine

chứ không phải decision maker.