Bỏ qua

Thiết kế Hệ thống ML

Thiết kế hệ thống ML vận dụng các mẫu hạ tầng từ các file 01-03 vào những thách thức cụ thể của học máy. File này bao quát vòng đời ML, quản lý dữ liệu, hạ tầng huấn luyện, đánh giá mô hình, chiến lược phục vụ (serving), đặc trưng kỹ thuật (feature engineering), pipeline ML và giám sát.

  • Một câu hỏi phỏng vấn thiết kế hệ thống như "Thiết kế một hệ thống gợi ý cho YouTube" không yêu cầu bạn mô tả thuật toán gợi ý. Nó yêu cầu bạn thiết kế toàn bộ hệ thống: pipeline dữ liệu, đặc trưng kỹ thuật, huấn luyện mô hình, đánh giá, phục vụ, giám sát và lặp lại cải tiến. File này cung cấp khung làm việc đó.

Vòng đời Hệ thống ML

Vòng đời hệ thống ML: từ xác định bài toán qua triển khai và giám sát, với vòng lặp cải tiến liên tục

  • Mọi hệ thống ML đều tuân theo cùng một vòng đời, dù đó là một bộ lọc thư rác hay một mô hình nền tảng:
Xác định bài toán → Dữ liệu → Đặc trưng → Huấn luyện → Đánh giá → Triển khai → Giám sát → Cải tiến
       ↑                                                                                    │
       └────────────────────────────────────────────────────────────────────────────────────┘

Xác định bài toán (Problem Framing)

  • Trước khi đụng đến dữ liệu hay mô hình, hãy định nghĩa:

    • Dự đoán cái gì? (xác suất click, token tiếp theo, hộp giới hạn đối tượng)
    • Người dùng là ai? (người dùng cuối, nhà phân tích nội bộ, các mô hình ML khác)
    • Các ràng buộc là gì? (độ trễ < 100ms, batch ngoại tuyến là đủ, phải chạy trên thiết bị)
    • Chỉ số kinh doanh là gì? (doanh thu, mức độ tương tác, độ chính xác) và chỉ số ML liên hệ với nó ra sao?
    • Đường cơ sở (baseline) là gì? (heuristic, hệ thống dựa trên luật, mô hình hiện có) — bạn phải đánh bại nó để biện minh cho hệ thống ML.
  • Lỗi thường gặp: nhảy vọt sang kiến trúc mô hình trước khi hiểu bài toán. "Chúng ta nên dùng một transformer" không phải là một câu trả lời thiết kế hệ thống. "Ta cần dự đoán xác suất click cho 10 triệu ứng viên trong vòng 200ms, nên cần một hệ thống hai giai đoạn: truy xuất nhanh trước, rồi đến một mô hình xếp hạng nhỏ" mới là câu trả lời đúng.

Quản lý Dữ liệu

Thu thập và Gán nhãn

  • Nhãn tường minh (explicit labels): con người gán nhãn dữ liệu (click/không-click, hộp giới hạn đối tượng, đánh giá chất lượng hội thoại). Tốn kém (khoảng \(0,02-\)10 mỗi nhãn tùy độ phức tạp), chậm và chủ quan.

  • Nhãn ngầm (implicit labels): suy ra nhãn từ hành vi người dùng. Click, thời gian lưu lại trang, lượt mua, bỏ qua. Rẻ và dồi dào nhưng nhiều nhiễu (một cú click không có nghĩa là hài lòng; một lần bỏ qua không có nghĩa là không thích).

  • Gán nhãn theo chương trình (programmatic labelling - Snorkel): viết các hàm gán nhãn (heuristic, regex, các mô hình hiện có) để bỏ phiếu cho mỗi ví dụ. Tổng hợp các phiếu bầu theo thống kê để tạo ra nhãn xác suất. Mở rộng được tới hàng triệu ví dụ với độ chính xác trung bình.

  • Học chủ động (active learning): mô hình xác định những ví dụ nó không chắc chắn nhất và yêu cầu con người gán nhãn cho những ví dụ đó. Cách này tối đa hóa hiệu quả gán nhãn: 1000 nhãn được chọn chủ động có thể tương đương 10.000 nhãn ngẫu nhiên.

Chất lượng Dữ liệu

  • Kiểm validate dữ liệu (data validation): kiểm tra mỗi batch dữ liệu đầu vào về các vi phạm schema (thiếu trường, sai kiểu), dịch chuyển phân bố (giá trị trung bình thay đổi đáng kể) và dị thường về dung lượng (kỳ vọng 1 triệu dòng, nhận được 500 nghìn).

  • Great ExpectationsTFX Data Validation là các công cụ định nghĩa các kỳ vọng về dữ liệu và cảnh báo khi chúng bị vi phạm.

  • Versioning dữ liệu: mọi lượt huấn luyện phải tái tạo được. DVC (chương 15) theo dõi các tệp dữ liệu cùng với mã nguồn. Mỗi phiên bản tập dữ liệu nhận một mã băm (hash); cấu hình huấn luyện tham chiếu đến mã băm đó.

Kho Đặc trưng (Feature Stores)

Kho đặc trưng: cùng một phép tính đặc trưng cung cấp cả kho ngoại tuyến (cho huấn luyện) và kho trực tuyến (cho phục vụ), ngăn chệch lệch huấn luyện-phục vụ

  • Kho đặc trưng (feature stores) (chương 15) cung cấp các đặc trưng nhất quán cho huấn luyện và phục vụ. Các khái niệm chính:

    • Đặc trưng ngoại tuyến (offline features): tính toán từ các pipeline batch (Spark), lưu trong kho dữ liệu (data warehouse). Dùng trong huấn luyện và suy luận batch. Ví dụ: độ dài phiên trung bình của người dùng trong 30 ngày, tổng số lượt mua của một món hàng.

    • Đặc trưng trực tuyến (online features): tính toán theo thời gian thực hoặc tính trước và phục vụ từ một kho lưu trữ độ trễ thấp (Redis, DynamoDB). Dùng trong suy luận thời gian thực. Ví dụ: 5 hành động gần nhất của người dùng, nội dung giỏ hàng hiện tại.

    • Chệch lệch huấn luyện-phục vụ (training-serving skew): nếu phép tính đặc trưng khác nhau giữa huấn luyện và phục vụ, mô hình sẽ thấy các giá trị đặc trưng khác nhau khi suy luận so với khi được huấn luyện. Kho đặc trưng loại bỏ điều này bằng cách dùng cùng một phép tính cho cả hai.

Hạ tầng Huấn luyện

  • Với đối tượng độc giả của cuốn sách này, huấn luyện phân tán đã được đề cập sâu ở chương 6 (song song dữ liệu, song song mô hình, độ chính xác hỗn hợp, định luật mở rộng). Ở đây ta tập trung vào các khía cạnh hệ thống:

  • Theo dõi thí nghiệm (experiment tracking) (W&B, MLflow — chương 15): mỗi lượt huấn luyện ghi lại siêu tham số, chỉ số, commit git, phiên bản dữ liệu và phần cứng. Đây là bản tương đương của kiểm soát phiên bản (version control) dành cho mô hình.

  • Tinh chỉnh siêu tham số (hyperparameter tuning): tìm kiếm tự động trên các siêu tham số. Các phương pháp: grid search (cạn kiệt, tốn kém), random search (hiệu quả một cách đáng ngạc nhiên), tối ưu hóa Bayes (mô hình hóa hàm mục tiêu, lấy mẫu ở nơi có khả năng cải thiện), và ASHA (Asynchronous Successive Halving - chia tán bất đồng bộ: bắt đầu nhiều thử nghiệm, loại sớm những thử nghiệm yếu kém).

  • Điều phối pipeline huấn luyện (Airflow, Kubeflow — chương 15): tự động hóa chuỗi chuẩn bị dữ liệu → huấn luyện → đánh giá → đăng ký. Lên lịch huấn luyện lại hàng ngày. Cảnh báo khi thất bại.

Đánh giá Mô hình

Đánh giá Ngoại tuyến (Offline)

  • Tập kiểm tra giữ riêng (held-out test set): đánh giá trên dữ liệu mà mô hình chưa từng thấy trong huấn luyện. Là tiêu chuẩn nhưng có thể gây hiểu lầm nếu tập kiểm tra không đại diện cho dữ liệu thực tế (production).

  • Đánh giá theo lát cắt (slice-based evaluation): đánh giá trên các nhóm con (theo nhân khẩu học người dùng, loại nội dung, ngôn ngữ, khoảng thời gian). Một mô hình có độ chính xác tổng thể 95% có thể chỉ đạt 70% với một nhóm thiểu số cụ thể — điều không thể chấp nhận.

  • Backtesting: với dự báo chuỗi thời gian hoặc dự đoán tuần tự, hãy đánh giá trên dữ liệu lịch sử theo thứ tự thời gian. Huấn luyện trên dữ liệu đến thời điểm \(t\), đánh giá trên dữ liệu từ \(t\) đến \(t + \Delta t\). Tránh rò rỉ (leakage) khi dùng dữ liệu tương lai để huấn luyện.

Đánh giá Trực tuyến (Online)

A/B testing: chia ngẫu nhiên người dùng thành nhóm đối chứng (mô hình cũ) và nhóm thử nghiệm (mô hình mới), so sánh các chỉ số với ý nghĩa thống kê

  • A/B testing: chia ngẫu nhiên lưu lượng thực tế thành nhóm đối chứng (mô hình cũ) và nhóm thử nghiệm (mô hình mới). So sánh các chỉ số kinh doanh (doanh thu, mức độ tương tác, tỷ lệ giữ chân) với ý nghĩa thống kê. Đây là tiêu chuẩn vàng để đánh giá các thay đổi ML.

    • Kích thước mẫu (sample size): bạn cần đủ dữ liệu để phát hiện kích thước hiệu ứng kỳ vọng. Cải thiện 0,1% tỷ lệ click-through cần hàng triệu lượt hiển thị (impressions) để phát hiện có ý nghĩa.

    • Thời gian: chạy ít nhất một chu kỳ đầy đủ (1-2 tuần với hầu hết sản phẩm) để nắm bắt hiệu ứng ngày trong tuần.

    • Chỉ số chắn (guardrail metrics): giám sát các chỉ số không được phép thay đổi (thời gian tải trang, tỷ lệ lỗi, tỷ lệ sập ứng dụng) song song với chỉ số mục tiêu. Một mô hình tăng doanh thu nhưng cũng tăng tỷ lệ sập là một kết quả tiêu cực ròng.

  • Triển khai bóng (shadow deployment): chạy mô hình mới cạnh mô hình cũ trong môi trường thực tế. Cả hai đều nhận cùng các yêu cầu, nhưng chỉ dự đoán của mô hình cũ được phục vụ cho người dùng. So sánh đầu ra. Cách này bắt được các lỗi và vấn đề chất lượng mà không gây rủi ro cho người dùng.

  • Xen kẽ (interleaving): với các bài toán xếp hạng, hãy xen kẽ kết quả từ mô hình cũ và mới trong một danh sách duy nhất. Người dùng tương tác với danh sách đã xen kẽ, và bạn đo lường kết quả mô hình nào được tương tác nhiều hơn. Cần ít người dùng hơn A/B testing để đạt ý nghĩa thống kê.

Phục vụ Mô hình (Model Serving)

Batch so với Thời gian thực

  • Suy luận batch (batch inference): tính trước dự đoán cho tất cả đầu vào có thể có. Lưu trong cơ sở dữ liệu/bộ nhớ đệm. Phục vụ từ bộ nhớ đệm. Phù hợp khi: không gian đầu vào hữu hạn (gợi ý cho mọi người dùng mỗi đêm), tính tươi mới không quan trọng (dự đoán hàng ngày là ổn), và dung sai độ trễ cao.

  • Suy luận thời gian thực (real-time inference): tính dự đoán theo yêu cầu cho mỗi truy vấn. Phù hợp khi: không gian đầu vào vô hạn (bất kỳ truy vấn nào của người dùng), tính tươi mới quan trọng (dự đoán cho truy vấn cụ thể này ngay bây giờ), và độ trễ phải thấp.

  • Nhiều hệ thống dùng cả hai: batch tính trước một tập ứng viên (rẻ, phủ 80% lưu lượng), thời gian thực xử lý phần còn lại (tốn kém, phủ các truy vấn đuôi và người dùng mới).

Versioning và Registry Mô hình

  • Một registry mô hình (model registry) (MLflow, W&B, SageMaker) lưu các mô hình đã huấn luyện cùng siêu dữ liệu (metadata):

    • Số phiên bản và ngày huấn luyện.
    • Cấu hình huấn luyện và phiên bản dữ liệu.
    • Chỉ số đánh giá (độ chính xác, độ trễ, dung lượng bộ nhớ sử dụng).
    • Giai đoạn: development → staging → production → archived.
  • Rollback: nếu một mô hình mới làm suy giảm chỉ số trong thực tế, hãy hoàn nguyên về phiên bản trước ngay lập tức. Registry giúp thao tác này chỉ bằng một cú click.

Đặc trưng Kỹ thuật (Feature Engineering)

  • Đặc trưng kỹ thuật (feature engineering) chuyển đổi dữ liệu thô thành các đầu vào mà mô hình cần. Đây thường là hoạt động có đòn bẩy cao nhất trong ML: đặc trưng tốt hơn cải thiện mọi mô hình, trong khi mô hình tốt hơn thì bị giới hạn bởi các đặc trưng nó nhận được.

Đặc trưng Trực tuyến so với Ngoại tuyến

  • Đặc trưng ngoại tuyến (offline features) được tính trước và thay đổi chậm (nhân khẩu học người dùng, các giá trị tổng hợp 30 ngày). Tính bởi các pipeline batch (Spark), lưu trong kho đặc trưng.

  • Đặc trưng trực tuyến (online features) phản ánh trạng thái hiện tại và thay đổi nhanh (món hàng trong giỏ, hành động cuối, vị trí hiện tại). Tính theo thời gian thực từ các luồng sự kiện hoặc tra cứu từ một kho lưu trữ nhanh.

  • Độ tươi mới của đặc trưng (feature freshness): một số đặc trưng cần tươi mới trong vài giây (phát hiện gian lận: giao dịch này có bất thường so với 5 giao dịch trước không?). Những đặc trưng khác có thể cũ vài giờ cũng được (gợi ý: người dùng này thích thể loại nào dựa trên lịch sử?). Đặc trưng tươi mới hơn thì tốn kém hơn để tính và phục vụ.

Các Mẫu Đặc trưng Thường gặp

  • Đặc trưng đếm (counting features): số sự kiện trong một cửa sổ thời gian (lượt mua trong 7 ngày qua, lượt đăng nhập trong 24 giờ qua).

  • Đặc trưng embedding: các embedding được học cho các biến phân loại (embedding người dùng, embedding món hàng, embedding truy vấn). Đây là đầu vào cho các mô hình hai tòa tháp (two-tower) và các kiến trúc tương tự.

  • Đặc trưng chéo (cross features): tổ hợp của hai hay nhiều đặc trưng (độ tuổi người dùng × danh mục món hàng). Nắm bắt các tương tác mà đặc trưng đơn lẻ bỏ sót.

  • Đặc trưng thời gian (temporal features): thời gian kể từ hành động cuối, thứ trong tuần, giờ trong ngày. Nắm bắt các mẫu thời gian.

  • Đặc trưng tổng hợp (aggregation features): trung bình, trung vị, min, max, độ lệch chuẩn của một đặc trưng số trên một nhóm (điểm đánh giá trung bình của các món hàng do người bán này bán).

Pipeline ML

  • Một pipeline ML điều phối toàn bộ quy trình từ dữ liệu đến mô hình đã triển khai:
Thu thập dữ liệu → Kiểm validate → Đặc trưng kỹ thuật → Huấn luyện → Đánh giá → Đăng ký → Triển khai → Giám sát
  • Mỗi bước là một task trong công cụ điều phối (Airflow, Kubeflow, Metaflow — chương 15). Pipeline:

    • Chạy theo lịch (huấn luyện lại hàng ngày) hoặc theo trigger (có dữ liệu mới).
    • Có tính bất biến (idempotent - chạy lại cho cùng kết quả).
    • Có logic retry (nếu tính đặc trưng thất bại, thử lại 3 lần với backoff).
    • Sinh ra các artifact (mô hình đã huấn luyện, báo cáo đánh giá, thống kê đặc trưng) được versioning và lưu trữ.
  • Metaflow (Netflix/Outerbounds) đặc biệt phù hợp cho ML: nó versioning mã nguồn, dữ liệu và mô hình cùng nhau, hỗ trợ phát triển cục bộ và thực thi trên cloud với cùng một mã, và tích hợp với K8s và AWS.

Giám sát (Monitoring)

  • Chúng ta đã đề cập các nguyên lý giám sát cơ bản ở chương 15 (Prometheus, Grafana, cảnh báo). Ở đây ta tập trung vào giám sát đặc thù cho ML:

Dịch chuyển Dữ liệu (Data Drift)

  • Dịch chuyển dữ liệu (data drift) xảy ra khi phân bố của dữ liệu đầu vào thay đổi so với dữ liệu huấn luyện. Một mô hình được huấn luyện trên dữ liệu mùa hè có thể hoạt động kém trên dữ liệu mùa đông (hành vi người dùng khác, tình trạng hàng hóa khác).

  • Phát hiện: so sánh phân bố các đặc trưng đầu vào với phân bố huấn luyện bằng các kiểm định thống kê:

    • Kiểm KS (Kolmogorov-Smirnov): so sánh hai phân bố thực nghiệm. Kiểm tra xem chúng có cùng đến từ một phân bố nền hay không.
    • PSI (Population Stability Index - Chỉ số Ổn định Quần thể): đo mức độ dịch chuyển của một phân bố. PSI < 0,1 là ổn định, 0,1-0,25 là dịch chuyển trung bình, > 0,25 là dịch chuyển đáng kể.
    • Dịch chuyển embedding (embedding drift): so sánh phân bố embedding của các truy vấn đầu vào với tập huấn luyện bằng khoảng cách tâm (centroid distance) hoặc MMD (Maximum Mean Discrepancy - Sai biệt Trung bình Cực đại).

Dịch chuyển Khái niệm (Concept Drift)

  • Dịch chuyển khái niệm (concept drift) xảy ra khi mối quan hệ giữa đầu vào và đầu ra thay đổi. Các đặc trưng trông giống nhau, nhưng dự đoán đúng lại khác. Ví dụ: sở thích người dùng thay đổi sau một sự kiện văn hóa, đại dịch, hoặc thay đổi sản phẩm.

  • Dịch chuyển khái niệm khó phát hiện hơn dịch chuyển dữ liệu vì nó đòi hỏi dữ liệu có nhãn. Hãy giám sát các chỉ số proxy: tỷ lệ click-through, tỷ lệ chuyển đổi, điểm hài lòng người dùng. Suy giảm bền vững gợi ý có dịch chuyển khái niệm.

Suy giảm Mô hình (Model Degradation)

  • Các mô hình suy giảm theo thời gian vì nhiều lý do: dịch chuyển dữ liệu, dịch chuyển khái niệm, lỗi pipeline đặc trưng (một đặc trưng bắt đầu trả về null), và thay đổi dữ liệu đầu nguồn (một API bên thứ ba đổi định dạng phản hồi).

  • Phản ứng: khi phát hiện suy giảm, hành động tùy thuộc vào mức độ nghiêm trọng:

    • Nhẹ: huấn luyện lại trên dữ liệu gần đây (huấn luyện lại theo lịch sẽ xử lý việc này).
    • Trung bình: điều tra nguyên nhân gốc (đặc trưng nào thay đổi? phân khúc người dùng nào bị ảnh hưởng?).
    • Nghiêm trọng: hoàn nguyên ngay về một phiên bản mô hình trước, rồi mới điều tra.

Vòng lặp Phản hồi (Feedback Loops)

  • Các hệ thống ML tạo ra vòng lặp phản hồi (feedback loops): dự đoán của mô hình ảnh hưởng đến hành vi người dùng, thứ trở thành dữ liệu huấn luyện cho phiên bản mô hình tiếp theo. Các vòng lặp này có thể là thiện hoặc ác.

  • Vòng lặp phản hồi tích cực (positive feedback loop) (nguy hiểm): một mô hình gợi ý chủ yếu hiển thị các món hàng phổ biến → người dùng click vào các món phổ biến (vì đó là tất cả những gì họ thấy) → mô hình học rằng các món phổ biến càng phổ biến hơn → sự đa dạng sụp đổ. Mô hình tự tạo ra dữ liệu xác nhận các thiên vị của nó.

  • Vòng lặp phản hồi tiêu cực (negative feedback loop) (cũng nguy hiểm): một mô hình phát hiện gian lận bắt được tất cả gian lận loại A → không có gian lận loại A nào đến được dữ liệu huấn luyện → mô hình tiếp theo không học được cách phát hiện loại A → gian lận loại A tái xuất hiện.

  • Biện pháp giảm thiểu (mitigations):

    • Khám phá (exploration): hiển thị một số món hàng mà mô hình không chắc chắn (epsilon-greedy, Thompson sampling). Cách này sinh ra dữ liệu huấn luyện đa dạng.
    • Ghi log phản thực tế (counterfactual logging): ghi lại mô hình sẽ dự đoán gì, không chỉ những gì người dùng thấy. Huấn luyện trên dữ liệu phản thực tế để giảm thiên vị.
    • Tập giữ riêng (holdout sets): phục vụ ngẫu nhiên một phần lưu lượng không qua lọc của mô hình. Dữ liệu không được lọc cung cấp Ground truth để đánh giá chất lượng mô hình.
    • Nhãn trễ (delayed labels): chờ kết quả thực sự trước khi dùng dữ liệu để huấn luyện. Một lượt gợi ý được click hôm nay có thể bị hối tiếc ngày mai. Một dự đoán gian lận phải chờ cửa sổ chargeback (hoàn tiền, 30-90 ngày).

Quản lý Bảng Embedding

  • Các hệ thống ML quy mô lớn thường có các bảng embedding với 100 triệu+ mục (một embedding cho mỗi người dùng, món hàng, quảng cáo hoặc thực thể). Quản lý chúng ở quy mô này là một thách thức hệ thống:

  • Lưu trữ: 100 triệu thực thể × 256 chiều × float16 = 50 GB. Không vừa với bộ nhớ GPU. Giải pháp: lưu trong bộ nhớ CPU với bộ nhớ đệm phía GPU, chia mảnh (shard) qua nhiều máy, hoặc dùng hash embeddings (băm các thực thể vào một bảng có kích thước cố định, chấp nhận xung đột).

  • Cập nhật: embedding thay đổi khi mô hình huấn luyện lại. Triển khai một bảng embedding mới lên môi trường phục vụ đòi hỏi: nạp 50 GB vào bộ nhớ mà không làm gián đoạn lưu lượng thực tế, xác minh tính đúng đắn, và hoàn nguyên nếu chỉ số suy giảm. Dùng triển khai blue-green cho các bảng embedding.

  • Sự cũ kỹ (staleness): một người dùng mới tạo không có embedding (vấn đề khởi động nguội - cold start). Giải pháp: dùng một embedding mặc định, suy ra embedding từ các đặc trưng của người dùng qua một mô hình feature-to-embedding, hoặc quay về một mô hình không cá nhân hóa.

Công bằng và Thiên vị (Fairness and Bias)

  • Các hệ thống ML có thể đối xử có hệ thống khác nhau với các nhóm khác nhau, thường phản ánh các thiên vị trong dữ liệu huấn luyện. Giám sát công bằng (fairness monitoring) là một trách nhiệm, không phải tính năng tùy chọn.

  • Các chỉ số cần giám sát:

    • Tương đương nhân khẩu học (demographic parity): tỷ lệ dự đoán dương có khác nhau giữa các nhóm (giới tính, sắc tộc, tuổi) không?
    • Cơ hội bình đẳng (equal opportunity): tỷ lệ dương thật (true positive rate) có khác nhau giữa các nhóm không? (Một mô hình tuyển dụng nên giỏi như nhau trong việc nhận diện ứng viên đủ tiêu chuẩn từ mọi nhóm.)
    • Hiệu chuẩn (calibration): nếu mô hình nói P(đủ tiêu chuẩn) = 0,7 cho nhóm A, thì có 70% nhóm A thực sự đủ tiêu chuẩn không? Và tương tự cho nhóm B?
  • Các bước thực tế:

    • Đánh giá hiệu năng mô hình trên các lát cắt (nhóm con) chứ không chỉ các chỉ số tổng thể.
    • Đưa các chỉ số công bằng vào pipeline đánh giá mô hình (một mô hình cải thiện độ chính xác tổng thể nhưng làm suy giảm một nhóm cụ thể không được triển khai nếu chưa qua rà soát).
    • Ghi chép các hạn chế và chế độ thất bại đã biết.
    • Thiết lập quy trình rà soát cho các mô hình triển khai trong các lĩnh vực nhạy cảm (tuyển dụng, cho vay, tư pháp hình sự, y tế).