Continuous Integration (CI)

Tích hợp liên tục (CI) là thực hành thường xuyên, tối thiểu mỗi ngày, hợp nhất các thay đổi của từng nhà phát triển vào nhánh main dùng chung, đồng thời tự động build và kiểm thử từng thay đổi, nhờ đó vấn đề tích hợp xuất hiện trong vài phút thay vì đợi đến lúc phát hành. Grady Booch đề xuất thuật ngữ này năm 1991, Kent Beck đưa nó thành thực hành cốt lõi của Extreme Programming vào cuối thập niên 1990, còn bài viết Tích hợp liên tục của Martin Fowler mô tả quy trình mà hầu hết nhóm vẫn làm theo. Trong machine learning (ML), CI còn kiểm tra dữ liệu, code huấn luyện và hành vi của model, vì một thay đổi có thể khiến mọi unit test đều đạt nhưng vẫn làm giảm độ chính xác của model.

Cách pipeline CI hoạt động#

Khi nhà phát triển đẩy một nhánh hoặc mở pull request, dịch vụ CI như GitHub Actions, GitLab CI/CD hoặc Jenkins khởi chạy một runner mới, checkout code, cài dependency và chạy pipeline gồm nhiều job: linter và công cụ kiểm tra kiểu, unit test, integration test, cùng quá trình build package hoặc image container. Mỗi job gửi trạng thái về pull request; quy tắc bảo vệ nhánh có thể chặn việc hợp nhất cho đến khi mọi bước kiểm tra bắt buộc đều đạt. Pipeline thường lặp lại cùng bộ kiểm thử trên ma trận hệ điều hành và phiên bản Python, đồng thời chạy lại toàn bộ bộ kiểm thử trên nhánh main sau mỗi lần hợp nhất. Tốc độ là một phần của thực hành này: Extreme Programming của Beck đặt mục tiêu mười phút để build toàn bộ hệ thống và chạy mọi bài kiểm thử, bởi bản build chậm sẽ ít được chạy hơn.

CI cho machine learning#

Dự án ML bổ sung các bước kiểm tra riêng. Kiểm thử dữ liệu xác nhận dữ liệu huấn luyện mới khớp với schema dự kiến, mọi tệp nhãn đều phân tích cú pháp được và không ảnh nào xuất hiện trong cả tập huấn luyện lẫn tập validation, điều có thể gây ra rò rỉ dữ liệu. Kiểm thử nhanh huấn luyện model trong một epoch trên bộ dữ liệu nhỏ để phát hiện lỗi shape và sự cố chỉ trong vài phút. Các bài kiểm thử so sánh đầu ra của model cố định seed ngẫu nhiên và cho phép sai số số học nhỏ, vì kernel GPU và thứ tự tải dữ liệu có thể làm thay đổi kết quả dấu phẩy động giữa các lần chạy. Cổng kiểm soát chất lượng chấm điểm model trên tập validation cố định và đánh dấu build thất bại nếu chỉ số như độ chính xác trung bình (mAP) thấp hơn ngưỡng; kiểm thử export xác nhận các phiên bản ONNX hoặc TensorRT của model vẫn tải được và đạt điểm tương tự model gốc. Huấn luyện đầy đủ mất nhiều thời gian và runner GPU rất tốn kém, vì vậy các nhóm thường chạy bước kiểm tra nhanh trên mọi pull request, còn huấn luyện lại đầy đủ và triển khai model được dành cho các lượt chạy theo lịch hoặc trên nhánh main; các công cụ quản lý phiên bản như DVC giúp mỗi job lấy đúng phiên bản bộ dữ liệu cần dùng.

Chế độ benchmark của Ultralytics YOLO hoạt động như một cổng kiểm soát như vậy: khi đặt verbose thành số thực như 0.216, chế độ này báo lỗi nếu export thất bại hoặc mAP_50-95 của bất kỳ định dạng export nào không vượt ngưỡng đó; CI của chính kho mã Ultralytics dùng chế độ này để kiểm thử các bản export YOLO26 trên runner Linux, macOS và ARM. Một workflow GitHub Actions tối giản kết hợp unit test với cổng kiểm soát đó:

name: CI
on:
  pull_request:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-python@v6
        with:
          python-version: "3.13"
      - run: pip install ultralytics pytest
      - run: pytest tests/
      # Fail if the ONNX export breaks or its mAP50-95 is not above the 0.216 floor
      - run: yolo benchmark model=yolo26n.pt format=onnx imgsz=160 verbose=0.216

Mọi pull request và mọi lần đẩy lên main đều chạy job trên runner Ubuntu mới. Unit test thất bại hoặc model ONNX đạt điểm bằng hay thấp hơn ngưỡng trên bộ dữ liệu COCO8 nhỏ sẽ khiến bước kiểm tra báo lỗi trước khi thay đổi được hợp nhất.

CI so với CD, MLOps và huấn luyện liên tục#

• Phân phối liên tục (CD): Tiếp nhận các bản build vượt qua CI và luôn giữ chúng ở trạng thái sẵn sàng phát hành, thường tự động triển khai sang môi trường staging. Triển khai liên tục tiến thêm một bước, đưa mọi thay đổi đạt yêu cầu lên production.
• MLOps: Lĩnh vực rộng hơn kết hợp CI và CD với quản lý phiên bản dữ liệu, triển khai model, giám sát và huấn luyện lại trong toàn bộ vòng đời ML.
• Huấn luyện liên tục (CT): Tự động huấn luyện lại và triển khai lại model khi có dữ liệu mới hoặc khi hoạt động giám sát phát hiện drift. Các cấp độ trưởng thành MLOps của Google xếp huấn luyện lại tự động ở cấp độ 1 và CI/CD tự động cho chính pipeline huấn luyện ở cấp độ 2.