Nền tảng đánh giá kỹ năng lập trình và kỹ năng nghề nghiệp tự động tích hợp AI

§1Định vị đề tài

Bài toán không phải “làm website cho sinh viên nộp bài rồi AI chấm”. Bài toán là xây một Assessment Engine có thể cấu hình: giảng viên khai báo kỹ năng, bài đánh giá, test case, rubric và trọng số; hệ thống tự thu bài, chạy nhiều bộ chấm độc lập, tổng hợp điểm theo công thức công khai và cập nhật hồ sơ kỹ năng của từng người học.

Bốn lớp giá trị

Đọc từ dưới lên: lớp dưới cung cấp dữ liệu cho lớp trên. Lớp Engine là “trái tim” — mọi loại bài đều đi qua nó.

Bốn nguyên tắc thiết kế xuyên suốt

1. Skill là thực thể trung tâm. Mỗi item chấm điểm phải khai báo nó đóng góp cho kỹ năng nào, bao nhiêu phần trăm.
2. Mọi điểm đều truy vết được nguồn. Bấm vào bất kỳ con số nào cũng xem được tiêu chí, bộ chấm và bằng chứng tạo ra nó.
3. AI không bao giờ là nguồn điểm duy nhất cho phần có thể kiểm chứng bằng test hoặc luật; AI chỉ là một evaluator trong pipeline.
4. Mã bài làm là không tin cậy. Chỉ được build và chạy trong container bị giới hạn, trên máy worker tách khỏi máy chủ chính.

§2Phạm vi & MVP

Rủi ro lớn nhất của đề tài là phình phạm vi. Danh sách MVP dưới đây được khoá ở cuối tuần 2; mọi thứ ngoài danh sách chỉ làm khi MVP đã chạy end-to-end.

§3Tác nhân & chức năng

Ba tác nhân người dùng, hai tác nhân hệ thống. Giảng viên là tác nhân quan trọng nhất vì mọi cấu hình chấm điểm đều do họ tạo ra.

Hành trình chính của sinh viên

Hành trình chính của giảng viên

Bước “chạy thử bằng lời giải mẫu” là bắt buộc trước khi publish: lời giải mẫu phải đạt 100% test, nếu không test case đang sai.

§4Mô hình miền

Mười một khái niệm dưới đây là ngôn ngữ chung của cả nhóm. Tên trong code, tên bảng và tên trong báo cáo dùng đúng các từ này.

// Quan hệ cốt lõi — phía cấu hình (giảng viên tạo)
Skill ◄──ItemSkill (ratio)──► Item ∈ Section ∈ Assessment
                               Item ──► Rubric ──► Criterion[] (weight, source)
                               Item ──► TestCase[] | Question[]

// Quan hệ cốt lõi — phía thực thi (sinh viên tạo, hệ thống chấm)
Attempt ──► Submission ──► Evaluation[] ──► ItemResult ──► AssessmentResult
                                               └──ItemSkill──► SkillScore ──► SkillSnapshot

§5Các loại bài đánh giá

Năm loại item dùng chung một pipeline chấm; khác nhau ở bộ chấm nào tham gia và tỉ trọng của chúng.

Hợp đồng nộp bài REST API

Đây là điểm nhấn của đề tài và cũng dễ hỏng nhất nếu không chuẩn hoá đầu vào. Sinh viên bắt đầu từ starter template do giảng viên cung cấp và phải tuân thủ:

• Dockerfile ở thư mục gốc; ứng dụng lắng nghe cổng 8080.
• GET /health trả 200 trong vòng 60 giây sau khi container khởi động.
• Dữ liệu nằm trong container (SQLite hoặc in-memory); không gọi dịch vụ bên ngoài.
• File nộp tối đa 20 MB. Trước khi nộp chính thức, sinh viên bấm Kiểm tra build để chạy thử build + health check, không tính điểm.

Giảng viên khai báo test case dạng YAML. Test chạy tuần tự, giá trị capture ở test trước được dùng lại ở test sau, nhờ đó kiểm tra được cả luồng CRUD và luồng đăng nhập lấy token:

id: TC03
name: Tạo sản phẩm hợp lệ
weight: 2
criterion: functional
request:
  method: POST
  path: /api/products
  headers: { Authorization: "Bearer {{token}}" }   # token capture từ TC01 /api/auth/login
  body: { name: "Keyboard", price: 25.5 }
expect:
  status: 201
  headers:
    Location: { exists: true }
  json:
    - { path: "$.id",    op: exists }
    - { path: "$.name",  op: equals, value: "Keyboard" }
    - { path: "$.price", op: gt,     value: 0 }
capture:
  productId: "$.id"    # TC04: GET /api/products/{{productId}} → 200

Toán tử kiểm tra cần hỗ trợ: equals, notEquals, exists, gt/lt, contains, notContains, matches (regex), count (độ dài mảng), schema (JSON Schema cho toàn bộ response).

Hợp đồng bài lập trình

§6Luồng chấm bất đồng bộ

API không bao giờ chấm bài trong một request. Nộp bài chỉ lưu và xếp hàng, trả 202 Accepted ngay; việc build, chạy và gọi AI diễn ra trên worker, có thể mất từ vài giây tới vài phút.

Vòng đời một bài nộp

§7Mô hình tính điểm

Câu hội đồng chắc chắn hỏi: “Backend = 83% được tính thế nào?”. Câu trả lời là bốn tầng công thức, mỗi tầng do giảng viên cấu hình, không tầng nào để AI tự quyết.

Tầng 1 · Tiêu chí        c ∈ [0, 100]
  Test : c = 100 × Σ w(test đạt) / Σ w(mọi test của tiêu chí)
  Rule : c = 100 × Σ w(luật đạt)  / Σ w(mọi luật)
  AI   : c = 10 × điểm AI (thang 0–10, bước 0.5, đã qua kiểm soát)
  Human: c = điểm giảng viên nhập, thay thế nguồn gốc, bắt buộc có lý do

Tầng 2 · Item            I = Σ c_k × w_k                 (Σ w_k = 1, theo rubric của item)
Tầng 3 · Assessment      A = Σ I_j × W_j / Σ W_j         (W_j: trọng số item trong bài)
Tầng 4 · Skill s         S = Σ I_j × m_js / Σ m_js       (m_js: tỉ lệ ItemSkill; mỗi item lấy lượt gần nhất)

Phiếu tính điểm mẫu — kỹ năng REST API của một sinh viên

Ba item gắn với skill REST API, tỉ lệ đóng góp 20% / 50% / 30% như đề xuất ban đầu.

Trong item B, phần do AI chấm chỉ chiếm 5%, dưới trần 20%: dù AI chấm lệch hẳn 2 điểm thì điểm item chỉ đổi 1 điểm trên thang 100. Skill profile chỉ hiển thị một kỹ năng khi có ít nhất 2 item làm bằng chứng; ít hơn thì ghi “chưa đủ dữ liệu” thay vì một con số ảo. Mỗi lần có kết quả mới, hệ thống lưu một SkillSnapshot để vẽ biểu đồ tiến bộ.

Tám cơ chế kiểm soát điểm AI

§8Sandbox & bảo mật thực thi

Chạy mã tuỳ ý là rủi ro bảo mật thật, không phải lý thuyết. Mỗi mối đe doạ dưới đây phải có một cấu hình cụ thể và một bài nộp độc hại tương ứng trong bộ kiểm thử.

# Lệnh worker dùng cho một test case bài Python (qua Docker.DotNet SDK)
docker run --rm -i --network none --cpus 1 --memory 256m --memory-swap 256m \
  --pids-limit 128 --read-only --tmpfs /tmp:size=64m \
  --user 10001:10001 --cap-drop ALL --security-opt no-new-privileges \
  -v /jobs/8f2c/src:/app:ro  asap-runner-python:3.12  python /app/main.py

Mỗi worker chạy tối đa 4 job song song (semaphore); cần nhiều hơn thì thêm worker thứ hai trỏ vào cùng hàng đợi — không phải sửa code.

§9Kiến trúc & công nghệ

Modular monolith: một API ASP.NET Core chia module theo nghiệp vụ, mỗi module một project, giao tiếp qua interface; cộng một tiến trình Worker riêng. Với 5 sinh viên và 1 VPS, cách này cho ranh giới module rõ ràng mà không phải trả chi phí vận hành microservices.

# Cấu trúc solution đề xuất (Asap = tên tạm)
src/
  Asap.Api/                   # host, controller, xác thực, SignalR hub
  Asap.Modules.Identity/      # SV1
  Asap.Modules.Assessment/    # SV2 · Skill, Assessment, Item, Rubric, TestCase
  Asap.Modules.Submission/    # SV3 · Attempt, Submission, trạng thái, enqueue
  Asap.Modules.AI/            # SV4 · IAiProvider, prompt, interview
  Asap.Modules.Scoring/       # SV5 · Score Engine, SkillScore, gợi ý
  Asap.Worker/                # SV3 · nhận job, Docker, HTTP test runner
  Asap.Shared/                # DTO, enum trạng thái, hợp đồng giữa module
web/                          # React + TS
runners/                      # Dockerfile runner: python, dotnet
tests/  deploy/docker-compose.yml  .github/workflows/

§10Dữ liệu & API

Thực thể theo module

Các endpoint chính

§11Phân công 5 thành viên

Chia theo module nghiệp vụ, không chia “người làm frontend, người làm backend”. Mỗi người sở hữu module của mình từ database tới giao diện.

Hợp đồng tích hợp phải chốt ở tuần 2

Quy tắc chung: mỗi PR có ít nhất 1 người review chéo; ai viết module nào thì viết unit test và integration test cho module đó.

§12Lộ trình 16 tuần

Mỗi sprint kết thúc bằng một lát cắt dọc chạy được từ giao diện tới database. Không dồn tích hợp vào cuối kỳ.

Mốc cắt phạm vi: nếu hết tuần 8 bài lập trình chưa chạy end-to-end, bỏ toàn bộ mục “Mở rộng” và dồn người hỗ trợ SV3.

§13Phi chức năng & kiểm thử

Mỗi yêu cầu phi chức năng phải có con số để kiểm chứng; nếu không đo được thì hội đồng không có lý do để tin.

“Hỗ trợ 100 submission đồng thời” trong đề xuất gốc nên hiểu là 100 bài được nhận và xếp hàng đồng thời, không phải 100 container chạy cùng lúc — một VPS không chạy nổi con số đó, và cũng không cần.

Chiến lược kiểm thử

# Pipeline CI/CD
Pull request → build → unit test → integration test (Testcontainers) → test bảo mật → docker build
merge main   → push image lên GHCR → SSH vào VPS → docker compose pull && docker compose up -d

§14Rủi ro

§15Cần chốt & chuẩn bị bảo vệ

Sáu quyết định cần chốt với giảng viên hướng dẫn

1. Ngôn ngữ cho bài lập trình — đề xuất Python + C#.
2. Stack cho bài REST API — đề xuất ASP.NET Core và Node/Express, mỗi stack một starter template.
3. AI provider và ngân sách — OpenAI hay Gemini, hạn mức token mỗi tháng.
4. Chính sách điểm AI — trần 20% cho Coding/REST có được chấp nhận không; bài phỏng vấn duyệt 100% hay duyệt mẫu.
5. Hạ tầng demo — VPS của trường hay cloud; có được một máy riêng cho worker không.
6. Thời lượng thực tế — 16 hay 20 tuần; quyết định có làm mục “Mở rộng” hay không.

Câu hỏi hội đồng dễ hỏi

“Điểm Backend 83% được tính thế nào?”

Mở phiếu tính điểm (§7): công thức 4 tầng, tỉ lệ ItemSkill do giảng viên cấu hình, bấm tới từng tiêu chí và bằng chứng.

“Nếu AI chấm sai thì sao?”

AI tối đa 20% điểm bài có test; lệch giữa hai lần chấm → giảng viên duyệt; mọi điểm có thể ghi đè kèm lý do; độ chính xác đã đo bằng MAE trên gold set.

“Sinh viên nộp mã độc thì sao?”

Trình diễn bộ bài độc hại ở §8 chạy trên CI: fork bomb, vòng lặp vô hạn, đọc file hệ thống, gọi mạng — tất cả bị chặn và vẫn nhận điểm 0 hợp lệ.

“Worker chết giữa chừng thì sao?”

Lease hết hạn, job được worker khác nhận lại, retry tối đa 3 lần, rồi vào DeadLetter; không bài nộp nào mất.

“Khác gì LeetCode hay HackerRank?”

Chấm cả dự án REST API thật và kỹ năng trình bày qua phỏng vấn, theo rubric giảng viên tự cấu hình, và quy tất cả về một hồ sơ kỹ năng theo thời gian.