Kỹ thuật chung này gọi là phân tích tác động kiểm thử (test impact analysis), và testmon là một cách miễn phí, mã nguồn mở để có được nó trong Python. Nó cũng hoàn toàn không phụ thuộc vào git: thứ nó đem ra so là những gì nó thấy ở lần chạy trước, dù code đó đã commit hay chưa.

Tuần này tôi đã thêm nó vào bộ kiểm thử Python của ứng dụng chợ mà tôi đang làm, và lý do không đơn thuần là muốn chạy nhanh hơn.

Vì sao tôi thêm nó

#

Một yêu cầu tính năng (feature request) thường rất nhỏ: một màn hình, một endpoint, hoặc một quy tắc cần hoạt động khác đi. Thế nhưng việc phải chạy toàn bộ bộ kiểm thử khiến yêu cầu nào cũng phình to hơn thực tế. Bộ kiểm thử có 2,248 bài kiểm thử Django, chạy với bốn tiến trình mất khoảng ba phút rưỡi, còn trên một tiến trình là 11 phút, và lần sửa nào cũng chạy hết toàn bộ, dù gần như tất cả các bài đều kiểm tra những thứ mà yêu cầu đó chưa hề động tới. Khi một bài chẳng liên quan gì bị thất bại, hoặc đơn giản là lần chạy cứ thong thả kéo dài, thì tính năng phải ngồi chờ. Nó bị giữ lại bởi những chuyện nằm ngoài yêu cầu tính năng, và thứ giữ nó lại lại chính là bộ kiểm thử của tôi.

Cách còn lại cũng chẳng tốt hơn: bỏ qua lần chạy toàn bộ, tự đoán xem tệp kiểm thử nào bao phủ thay đổi, và thỉnh thoảng đoán sai. Làm vậy thì nhanh, nhưng không chính xác, mà một thay đổi chưa được kiểm thử đã bị tôi đem phát hành thì cũng là một yêu cầu tính năng tôi sẽ phải làm lại lần thứ hai.

Những bài kiểm thử tôi phải chờ phải đúng là những bài mà thay đổi đó có thể chạm tới, không thừa một bài, không thiếu một bài. testmon cho tôi đúng tập hợp đó dựa trên dữ liệu đã ghi lại, chứ không phải dựa trên phỏng đoán. Bộ kiểm thử đầy đủ thì vẫn chạy, nhưng chạy trong CI, ở một chỗ không cản trở việc tiếp theo tôi đang làm.

Cách nó quyết định chạy bài nào

#

testmon chia mỗi tệp Python thành các khối: phần cấp cao nhất của module, từng class, từng hàm, trong đó thân của các hàm lồng bên trong được tách ra khỏi khối bao quanh nó. Nó lưu checksum của từng khối chứ không bao giờ lưu bản thân code. Trong lúc một bài kiểm thử chạy, coverage.py ghi lại những dòng được thực thi, còn testmon ghi nhận các dòng đó thuộc về khối nào. Ở đây không có phân tích tĩnh (static analysis), cũng không có chuyện đoán mò dựa vào các câu import. Một bài kiểm thử phụ thuộc vào đúng những khối mà nó đã chạy qua.

Lấy ví dụ một module như sau:

# pricing.py
def subtotal(items):
    return sum(item.price * item.quantity for item in items)

def discount(total, code):
    if code == "WELCOME10":
        return total * 0.9
    return total

Một bài kiểm thử chỉ gọi subtotal() sẽ phụ thuộc vào phần cấp cao nhất của module và thân hàm subtotal. Bạn có viết lại discount() thế nào đi nữa thì testmon cũng không chạy lại bài đó, vì nó chưa từng thực thi dòng nào của discount. Ngược lại, chỉ cần đổi một ký tự bên trong subtotal là bài đó chạy lại, kể cả khi thay đổi ấy không thể làm kết quả khác đi. testmon không cố tỏ ra thông minh với các tác dụng phụ: khối nào bạn đã thực thi mà bị thay đổi thì bạn chạy lại.

Nó còn theo dõi cả những thứ bao quanh code. Bản ghi bao gồm phiên bản Python và các gói đã cài cùng phiên bản của chúng. Nó không theo dõi biến môi trường: nếu cùng một bộ code chạy dưới hai module settings khác nhau, bạn phải đặt tên cho chúng bằng --testmon-env (bước 8), không thì chúng dùng chung một bản ghi. Nâng cấp Django thì mọi bài từng chạm vào Django lại bị tính là bị ảnh hưởng, mà trong một ứng dụng Django thì đó là tất cả.

Những gì nó không nhìn thấy

#

testmon theo dõi phần code Python mà bài kiểm thử thực thi. Nó không theo dõi những tệp khác mà bài kiểm thử đọc: template, JSON, văn bản, hay bất cứ thứ gì khác trên đĩa. Nó không theo dõi các dịch vụ được gọi qua mạng. Và những gì chạy một lần trước khi các bài kiểm thử bắt đầu thì nó không thể gắn vào một bài cụ thể nào.

Trong một dự án Django, trước hết đó là migration: chúng chỉ chạy một lần, lúc tạo cơ sở dữ liệu kiểm thử, nên không bài kiểm thử nào có chúng trong bản ghi của mình (script bọc ở bên dưới sẽ dựng lại cơ sở dữ liệu kiểm thử khi có migration mới). Tiếp đến là settings và code khởi động, chạy trong lúc pytest khởi động, nằm ngoài mọi bài kiểm thử riêng lẻ. Và cuối cùng là template cùng các tệp dữ liệu: template không phải là Python, nên sửa một template sẽ không làm chạy lại bài nào render nó.

Bộ kiểm thử của tôi còn có thêm vài trường hợp riêng. Một số bài đọc một tệp JSON chứa dữ liệu mẫu (fixture) dùng chung với bộ kiểm thử của ứng dụng di động. Một số bài kiểm tra gói web đã dựng (bundle), và một số khác kiểm tra đầu ra của một trang tĩnh được sinh ra ngay trong cùng kho mã. Đổi bất cứ thứ nào trong số đó, testmon sẽ vui vẻ báo cho bạn rằng chẳng cần chạy gì cả. Đó là lý do phần hướng dẫn bên dưới bọc testmon trong một script, để script nhận ra những tệp này và chạy toàn bộ khi có tệp nào đã thay đổi.

Cách thêm nó vào một dự án Django

#

Các bước dưới đây giả định bạn dùng pytest và pytest-django, cùng với uv để quản lý thư viện phụ thuộc. Nếu dùng pip thì thay uv add --dev bằng pip install và bỏ uv run đi.

1. Cài đặt.

uv add --dev pytest-testmon

2. Bảo đảm pytest chạy được bộ kiểm thử. testmon là một plugin của pytest, nên khi chạy bằng python manage.py test thì nó không làm gì cả. pytest-django cần biết module settings và các mẫu tên tệp mà bài kiểm thử của bạn dùng:

# pytest.ini
[pytest]
DJANGO_SETTINGS_MODULE = myproject.settings
python_files = tests.py test_*.py *_tests.py
python_classes = Test* *Tests *TestCase

Nếu từ trước đến giờ bộ kiểm thử chỉ chạy bằng trình chạy kiểm thử của Django, hãy chạy nó bằng pytest một lần và sửa hết những chỗ khác biệt trước khi thêm testmon. Nếu không, bạn sẽ phải gỡ lỗi hai thứ cùng một lúc.

3. Đừng để bản ghi lọt vào git. testmon ghi tệp .testmondata vào thư mục gốc của pytest. Đây là một cơ sở dữ liệu SQLite, nên bạn sẽ thấy cả các tệp -shm và -wal nằm cạnh nó, và script bên dưới còn thêm một tệp đánh dấu thời điểm (stamp). Chỉ một mẫu là đủ cho tất cả:

# .gitignore
.testmondata*

4. Ghi lại toàn bộ bộ kiểm thử một lần. testmon chưa chọn được gì cho đến khi nó đã thấy mọi bài kiểm thử chạy qua:

uv run pytest --testmon

Trong một bản checkout mới tinh, lần chạy đầu tiên đó là toàn bộ bộ kiểm thử trên một tiến trình. Ở dự án của tôi, lần đó mất khoảng 12 phút cho 2,248 bài. Từ đó trở đi, cũng lệnh này sẽ chỉ chạy những bài kiểm thử bị ảnh hưởng. Không có gì thay đổi thì nó không chạy gì cả.

Có hai chỗ dễ vấp. Với testmon 2.2.0 trở về trước, nó cần plugin cache của pytest: lần thử đầu tiên của tôi chạy với -p no:cacheprovider và bị sập với lỗi KeyError: 'lf' (bản 2.3.0 coi việc thiếu --lf là chưa đặt). Còn nếu bạn dùng Python 3.14 trở lên, hãy đặt COVERAGE_CORE=ctrace trước khi ghi. Lý do được giải thích ở phần “Lỗi trông như một lần chạy toàn xanh” phía dưới. Đây là dòng quan trọng nhất trong script bên dưới.

Cập nhật ngày 7 tháng 11: testmon 2.3.0, phát hành ngày 2 tháng 11, tự ép coverage dùng tracer C, nên với phiên bản này dòng export chỉ còn là cho chắc. Nếu bạn đang ở 2.2.0 trở về trước thì cứ giữ nó. Còn bước cố ý làm hỏng code để kiểm tra thì phiên bản nào cũng nên làm.

5. Bọc nó lại để lo những tệp nó không nhìn thấy. Đây là phần giúp bạn yên tâm dùng nó hằng ngày. Script giữ một tệp stamp từ lúc bắt đầu lần chạy trước. Nếu có tệp nào mà testmon không lần theo được lại mới hơn tệp stamp, script sẽ chạy toàn bộ và ghi lại từ đầu. Một migration mới thì chỉ khiến script dựng lại cơ sở dữ liệu kiểm thử. Còn không thì để testmon tự chọn. Một ví dụ đã cắt gọn:

#!/usr/bin/env bash
# scripts/test-changed.sh: the tests a change can affect, or all when in doubt.
#   scripts/test-changed.sh            # affected tests
#   scripts/test-changed.sh --all      # everything, re-recorded
#   scripts/test-changed.sh -k orders  # anything else goes to pytest
set -euo pipefail
cd "$(dirname "$0")/.."

# coverage's C tracer: from Python 3.14 coverage defaults to sys.monitoring,
# which reports a line only the first time a process runs it, so testmon
# would credit each line to one test. Changing this means --all.
export COVERAGE_CORE=ctrace

STAMP=.testmondata.started
full=false
rebuild=false
if [ "${1:-}" = "--all" ]; then
    full=true; shift
elif [ ! -f .testmondata ] || [ ! -f "$STAMP" ]; then
    echo "No record yet: running everything once."
    full=true
else
    # Changed since the last run started, and not traceable per test:
    # anything that isn't Python, plus settings and conftest.
    newer="$(find myapp myproject fixtures pytest.ini \
        -type f -newer "$STAMP" ! -path '*/migrations/*' \
        \( ! -name '*.py' -o -path 'myproject/settings*' -o -name 'conftest.py' \) \
        ! -path '*/__pycache__/*' | head -5)"
    if [ -n "$newer" ]; then
        echo "Changed, and not traceable per test:"; printf '  %s\n' $newer
        full=true
    fi
    # A new migration needs a fresh test database, not a full run.
    [ -n "$(find myapp -path '*/migrations/*.py' -newer "$STAMP" | head -1)" ] && rebuild=true
fi

# Stamp the start, so an edit made while the tests run counts next time.
started="$(mktemp .testmondata.run.XXXXXX)"
args=(--testmon --reuse-db)
# --create-db alone deletes the database when the run ends; with
# --reuse-db as well, the rebuilt one is kept for next time.
[ "$rebuild" = true ] && args=(--testmon --reuse-db --create-db)
[ "$full" = true ] && args=(--testmon-noselect --reuse-db --create-db)

status=0
uv run pytest "${args[@]}" -q "$@" || status=$?
# 0: passed, or nothing selected. 1: some failed (still recorded).
# 5: nothing collected at all.
case "$status" in 0|1|5) mv "$started" "$STAMP" ;; *) rm -f "$started" ;; esac
[ "$status" = 5 ] && exit 0
exit "$status"

Có hai chi tiết trong đó đáng giải thích. --reuse-db là cờ của pytest-django để giữ lại cơ sở dữ liệu kiểm thử giữa các lần chạy, và điều này trở nên quan trọng khi một lần chạy chỉ còn mất vài giây: tạo lại cơ sở dữ liệu mỗi lần có khi còn lâu hơn chính các bài kiểm thử. Lần chạy toàn bộ, hoặc lần chạy ngay sau khi có migration mới, thì thêm --create-db để cơ sở dữ liệu có đúng cấu trúc bảng (schema) hiện tại. Hãy giữ --reuse-db đi kèm với nó: nếu chỉ có --create-db thì pytest-django sẽ xóa cơ sở dữ liệu khi lần chạy kết thúc, và lần chạy sau lại phải dựng lại tất cả từ đầu.

Còn khi testmon bỏ chọn mọi bài, lần chạy sẽ thoát với mã 0, nên “không có gì thay đổi” được tính là qua. Mã thoát (exit code) 5 là cách pytest báo “không thu thập được bài kiểm thử nào”, và script cũng coi trường hợp đó là ổn.

Hãy để ý những gì không có trong danh sách: pyproject.toml và tệp khóa phiên bản (lock file). Phiên bản đầu tiên của tôi chạy toàn bộ mỗi khi tệp lock thay đổi, khiến phương án dự phòng chậm chạp kia bị kích hoạt gần như ngày nào cũng có, và mọi thứ còn tệ hơn cả lúc chưa có script. testmon vốn đã tự theo dõi phiên bản của các gói đã cài, nên chuyện này nó không cần ai giúp.

6. Cho nó cơ sở dữ liệu và bộ nhớ đệm riêng. Nếu trên cùng máy còn có thứ khác chạy kiểm thử, chẳng hạn một terminal thứ hai, một agent viết code (coding agent) hay manage.py test, hãy trỏ script tới một cơ sở dữ liệu kiểm thử riêng và một số hiệu bộ nhớ đệm riêng (trong ví dụ là database số 8 của Redis), để cơ sở dữ liệu được giữ lại không bao giờ đụng phải lần chạy của người khác:

export DATABASE_URL="postgresql://myapp:myapp@localhost:5432/myapp_changed"
export REDIS_URL="redis://localhost:6379/8"

7. Xóa sạch bộ nhớ đệm đó trước mỗi lần chạy. Chuyện này tôi phải vấp mới biết. Các lần chạy một phần bắt đầu thất bại với những lỗi KeyError mà lần chạy toàn bộ không hề gặp. Nguyên do là một số nhãn danh mục được cache mà không có thời hạn hết hạn, và một cơ sở dữ liệu kiểm thử giữ lại từ lần chạy này lại gặp phải bộ nhớ đệm vẫn còn “ấm” từ một lần chạy trước đó nữa. Xóa cache ngay đầu script là hết lỗi:

uv run python -c "import os, redis; redis.Redis.from_url(os.environ['REDIS_URL']).flushdb()"

Đó chính là testmon làm đúng như tài liệu của nó đã nói: mỗi lần chạy một tập con khác nhau sẽ làm lộ ra những bài kiểm thử chỉ qua được nhờ những gì đã chạy trước chúng. Chỗ cần sửa là phần thiết lập kiểm thử, không phải testmon.

8. Nắm các cờ để dùng khi testmon chọn sai.

• --testmon-noselect chạy mọi bài kiểm thử nhưng đưa những bài có khả năng thất bại lên trước. testmon tự chuyển sang chế độ này khi bạn truyền thêm -k, -m, --lf hoặc node ID của một bài kiểm thử.
• --testmon-forceselect chỉ chạy những bài bị ảnh hưởng mà đồng thời khớp với -k hoặc -m của bạn.
• --testmon-nocollect dùng bản ghi hiện có nhưng không ghi thêm gì vào. Chế độ này bị bật bắt buộc khi chạy dưới trình gỡ lỗi (debugger) hoặc khi coverage đang chạy sẵn.
• --no-testmon tắt nó cho một lần chạy, dùng khi bạn đã đặt nó trong addopts.
• --testmon-env=<name> giữ các bản ghi riêng biệt trong cùng một tệp, dành cho bộ kiểm thử mà bạn chạy dưới hai module settings khác nhau.

Nếu dự án có cả phần JavaScript thì Jest có sẵn một phiên bản riêng của tính năng này. jest --changedSince=main chạy những bài kiểm thử import bất cứ thứ gì đã thay đổi kể từ main, dựa theo các câu import chứ không dựa theo coverage. Tôi đã thêm nó vào package.json của ứng dụng dưới tên npm run test:changed, để cả hai nửa của dự án có cùng một thói quen. Một lần sửa ở một module tiện ích đã chọn ra 7 trong số 121 tệp kiểm thử của ứng dụng.

Nó tiết kiệm được gì

#

Khi script bọc đã vào chỗ, và sau khi sửa lỗi được kể ở phần tiếp theo, tôi đo thời gian của nó, tính cả phần khởi động:

Với một lần sửa thường ngày, như vậy là nhanh hơn khoảng 25 lần so với bộ kiểm thử chạy song song, còn khi không có gì thay đổi thì nhanh hơn khoảng hai trăm lần.

Bản ghi cũng cho thấy điều tương tự, ở phạm vi rộng hơn. Trong 307 tệp Python không phải tệp kiểm thử mà bộ kiểm thử chạy qua, thay đổi ở tệp trung vị chạm tới 22 bài kiểm thử, tức khoảng 8 giây thời gian kiểm thử. Ở đầu bên kia là vài module lõi: gần như bài kiểm thử nào cũng chạy qua chúng, nên một thay đổi ở đó chạm tới khoảng 1,500 bài, và testmon sẽ chạy lại phần lớn bộ kiểm thử. Đó là câu trả lời đúng, chứ không phải một thất bại. Các con số này là giới hạn trên tính theo từng tệp: testmon làm việc theo từng khối, nên đổi một hàm sẽ chỉ chọn những bài đã chạy qua hàm đó.

Cái giá lộ ra khi script bọc phải quay về phương án dự phòng. Một lần chạy toàn bộ cũng là một lần ghi trên một tiến trình giống như lần đầu, mất khoảng 12 phút, tức là còn chậm hơn bộ kiểm thử chạy song song mà nó thay thế. Nó chạy trên một tiến trình chỉ vì tôi chưa thử testmon cùng pytest-xdist; testmon đã hỗ trợ xdist từ bản 1.4, nên đó là thứ tiếp theo cần đo. Vì vậy, danh sách các tệp kích hoạt nó nên ngắn hết mức có thể, miễn là vẫn trung thực.

Lỗi trông như một lần chạy toàn xanh

#

Những con số đầu tiên của tôi còn đẹp hơn thế này: một lần sửa, 6 bài kiểm thử, 3.3 giây. Chúng sai, và không có gì trên màn hình cho biết điều đó.

Từ Python 3.14, coverage.py mặc định dùng một lõi (core) mới, xây dựng trên sys.monitoring của trình thông dịch. Lõi này chỉ báo một dòng ở lần đầu tiên một tiến trình chạy qua dòng đó. testmon dựng bản ghi bài nào đã chạy dòng nào từ dữ liệu của coverage, nên mỗi dòng chỉ được tính cho bài kiểm thử đầu tiên tình cờ chạy qua nó, chứ không tính cho bài nào khác. Sửa một dòng mà tám bài kiểm thử cùng dùng, testmon sẽ chỉ chọn một trong số đó.

Lỗi này lộ ra trên một dự án khác của tôi, nhỏ hơn, nơi tôi chép lại cách thiết lập này. Một phần của việc áp dụng nó ở đó là cố ý làm hỏng một dòng rồi so sánh kết quả, và các con số không khớp nhau. Quay lại bộ kiểm thử này, tôi làm đúng phép thử đó. Tôi làm hỏng một dòng trong phần code của banner ở màn hình chính, cụ thể là tiêu đề của một slide. Chạy pytest bình thường thì có 8 bài thất bại. testmon chỉ chọn 4. 4 bài hỏng còn lại không hề được chạy, và đầu ra không có dòng nào cho biết chúng đã bị bỏ qua.

Cách sửa chỉ là một dòng, export COVERAGE_CORE=ctrace, để đưa coverage về lại trình theo dõi (tracer) cổ điển viết bằng C của nó. Đổi tracer thì bản ghi cũng khác, nên tôi ghi lại từ đầu: 12 phút 3 giây cho 2,248 bài. Sau đó, cùng một kiểu sửa làm hỏng code như vậy đã chạy đủ cả 11 bài mà nó làm hỏng.

Cập nhật ngày 7 tháng 11: testmon 2.3.0, phát hành ngày 2 tháng 11, giờ tự đặt tracer C, cả trong tiến trình lẫn cho các tiến trình con, nên cài mới thì không cần dòng export này nữa. Phần kiểm tra ở đoạn tiếp theo thì vẫn cần.

Nếu phải truyền lại một bài học trước mọi thứ khác trong bài này, tôi sẽ chọn bài học này. Một công cụ chọn bài kiểm thử mà chọn quá ít thì trông y hệt như thành công: ít bài hơn, chạy nhanh hơn, toàn màu xanh. Vì vậy, khi thiết lập một công cụ như thế, hãy cố ý làm hỏng một thứ dùng chung, chạy cả bộ kiểm thử thông thường lẫn công cụ chọn bài, rồi kiểm tra xem hai bên có báo thất bại đúng những bài giống nhau không. Sau đó, làm lại việc này mỗi khi Python hoặc coverage.py lên phiên bản mới.

Khi agent viết code vào cuộc

#

Tôi không còn tự tay làm mọi thay đổi trong kho mã đó nữa. Một agent viết code, trong trường hợp của tôi là Claude Code, làm khá nhiều thay đổi nhỏ, và một agent tốt sẽ chạy kiểm thử sau mỗi lần sửa. Đứng trước một bộ kiểm thử 11 phút, nó cũng chỉ có đúng hai lựa chọn tồi như tôi từng có: ngồi chờ, hoặc đoán xem tệp kiểm thử nào mới quan trọng.

Vì vậy, phần hướng dẫn dành cho agent trong kho mã giờ ghi rằng script bọc kia là cách mặc định để chạy kiểm thử trong lúc làm việc, còn --all dành cho lần chạy toàn bộ. Sau mỗi lần sửa, agent nhận được đúng tập bài kiểm thử chính xác như tôi, chỉ trong vài giây. Đây cũng là lý do bước 6 cho script một cơ sở dữ liệu và bộ nhớ đệm riêng: vào một ngày bận rộn, sẽ có nhiều hơn một phiên làm việc cùng chạy kiểm thử trên một máy, và cơ sở dữ liệu được giữ lại tuyệt đối không được đụng phải lần chạy của người khác.

Không phần nào trong số này đòi hỏi testmon phải có gì dành riêng cho AI. Vẫn là bản ghi đó, vẫn là cách chọn đó. Chỉ là nó trở nên quan trọng hơn khi thứ đang tạo ra thay đổi lại tạo ra rất, rất nhiều thay đổi.

Vì sao CI chỉ nhận một phiên bản thô hơn

#

testmon không có chế độ dành riêng cho CI. Trên runner nó hoạt động y như trên laptop, và chính tác giả của nó viết rằng việc chia sẻ hoặc cache .testmondata giữa các runner CI kém hiệu quả hơn nhiều so với dịch vụ lưu trữ sẵn (hosted) của họ là testmon.net. Một bản ghi được cache lại cũng sẽ mù theo đúng những cách đã kể ở trên, mà CI của tôi lại chạy bộ kiểm thử bằng trình chạy của Django trên bốn tiến trình, nên tôi không đưa testmon vào CI.

Thay vào đó, CI nhận cùng ý tưởng này nhưng ở cấp độ tệp. Workflow kiểm tra giờ bắt đầu bằng một job nhỏ, lấy diff của lần push rồi xác định nó đã chạm vào nửa nào của kho mã: API Python, ứng dụng di động, cả hai, hay không bên nào. Trước đây, CI chạy cả job Python lẫn job ứng dụng ở mọi lần push, kể cả những lần chỉ sửa tài liệu. Giờ thì một lần push chỉ sửa tài liệu không chạy gì cả, còn một lần push chỉ đụng tới ứng dụng thì bỏ qua bộ kiểm thử Django. Tôi đã chạy thử (dry run) job này trên năm commit thật: commit chỉ sửa tài liệu không chạy gì, commit chỉ sửa ứng dụng bỏ qua job Python, còn commit chỉ sửa backend thì bỏ qua job ứng dụng. Một ví dụ đã cắt gọn:

jobs:
  changes:
    runs-on: ubuntu-latest
    outputs:
      python: ${{ steps.diff.outputs.python }}
    steps:
      - uses: actions/checkout@v7
        with:
          fetch-depth: 0
      - id: diff
        env:
          BEFORE: ${{ github.event.before }}
          HEAD: ${{ github.sha }}
        run: |
          FILES="$(git diff --name-only "$BEFORE" "$HEAD")"
          # Python's inputs include the non-Python files its tests read.
          PY='^(myapp/|myproject/|fixtures/shared\.json$|web/dist/|pyproject\.toml$|uv\.lock$)'
          if printf '%s\n' "$FILES" | grep -qE "$PY"; then
            echo "python=true" >> "$GITHUB_OUTPUT"
          else
            echo "python=false" >> "$GITHUB_OUTPUT"
          fi

  python:
    needs: changes
    if: needs.changes.outputs.python == 'true'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - run: uv run python manage.py test --parallel 4 --noinput

Workflow thật còn chạy toàn bộ khi không có khoảng commit nào để so sánh: một nhánh mới, một lần force push hoặc một lần chạy tay.

Điểm mù vẫn là điểm mù cũ, chỉ mang một hình dạng khác. testmon không nhìn thấy tệp JSON, và bộ lọc theo đường dẫn cũng vậy, trừ khi bạn liệt kê tệp đó ra. Vì thế, mẫu ở trên ghi rõ tên tệp fixture dùng chung, gói web đã dựng và trang được sinh ra, kèm một dòng chú thích nhắc người sửa nó giữ cho danh sách luôn đúng. Phiên bản cấp tệp thô hơn, nhưng khi sai thì sai về phía an toàn: chỉ cần bên phía Python có gì thay đổi là cả bộ kiểm thử sẽ chạy.

Có đáng không?

#

Với một bộ kiểm thử chạy mất vài phút thì có. Cái giá thật sự nằm ở những gì nó không nhìn thấy, và script bọc sinh ra là để lo việc đó. Dù vậy, chỗ của testmon là vòng lặp làm việc trên laptop. CI vẫn chạy toàn bộ bộ kiểm thử mỗi khi phía Python có thay đổi, và đó mới là lần chạy tôi tin tưởng trước khi triển khai.

Nếu bạn vào đây để tìm cách chạy Docker Compose trong GitHub Actions: tôi đã làm thế suốt hai năm rồi bỏ. Giờ CI khai báo cùng các image Postgres và Valkey đó dưới dạng services: và chạy thẳng trên runner đúng các lệnh uv run … và npm run …; Compose quay về làm thứ lập trình viên chạy ở máy mình. Phần còn lại là lý do, kèm các tệp.

Năm 2024 tôi có viết bài Dùng Docker Compose cho CI/CD thay vì YAML riêng của từng nền tảng, với ý chính là để logic dựng trong Compose, còn công cụ CI chỉ việc gọi nó. Hai năm sau, tôi xem lại toàn bộ các kho mã mà tôi đang dùng để phát hành. Có bốn kho có workflow, kho nào cũng chỉ có một người commit là tôi, và trong số các workflow đó không còn cái nào gọi docker compose nữa. Nguyên tắc thì vẫn đứng vững, còn cách làm thì không. Dưới đây là những thứ đã thay thế nó: phiên bản ví dụ đã cắt gọn của các tệp, thời gian từng bước mà GitHub ghi lại, và cả những phần ít tự động hơn so với mong đợi của mấy sơ đồ CI/CD.

Mọi quy trình tôi đang chạy, gói trong một bảng

#

Nói theo sách vở thì hai trang Hugo là triển khai liên tục, còn ứng dụng kia (một ứng dụng chợ kiêm cộng đồng mà tôi đang làm) là tích hợp liên tục cộng với phát hành bằng đúng một lệnh, tức là chuyển giao liên tục: phần kiểm tra báo cho tôi biết khi có gì sai, nhưng không chặn tôi triển khai. Tôi cố ý chia như vậy. Một bản cập nhật OTA sẽ đến mọi điện thoại đang dùng phiên bản ứng dụng mà nó nhắm tới, nên việc phát hành phải là một quyết định, chứ không phải tác dụng phụ của một lần merge. Còn API là nơi chạy migration cơ sở dữ liệu. Hai ứng dụng Django còn lại của tôi thì hoàn toàn không có workflow nào.

Phần CI: một workflow, hai job

#

Toàn bộ CI của ứng dụng nằm trong một tệp, .github/workflows/checks.yml. Trước ngày 11 tháng 10, ngay cả tệp này cũng chưa có. Đây là một ví dụ đã cắt gọn cho thấy hình dạng của nó:

# Lint, types and tests on every push and pull request to main.
# Nothing here deploys.
name: Checks

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

concurrency:
  group: checks-${{ github.ref }}
  cancel-in-progress: true

jobs:
  python:
    runs-on: ubuntu-latest
    timeout-minutes: 30
    services:
      postgres:
        image: postgres:17
        env:
          POSTGRES_USER: myapp
          POSTGRES_PASSWORD: myapp
          POSTGRES_DB: myapp
        ports: ["5432:5432"]
        options: >-
          --health-cmd "pg_isready -U myapp"
          --health-interval 5s --health-timeout 5s --health-retries 20
      valkey:
        image: valkey/valkey:8-alpine
        ports: ["6379:6379"]
    env:
      DEBUG: "True"
      DATABASE_URL: postgresql://myapp:myapp@localhost:5432/myapp
      REDIS_URL: redis://localhost:6379
      PYTHON_JIT: "0"   # match production
    steps:
      - uses: actions/checkout@v7
      - uses: astral-sh/setup-uv@v10
        with:
          enable-cache: true
          prune-cache: true
      - run: uv sync --locked
      - run: uv run ruff check .
      - run: uv run mypy myapp/
      - run: uv run python manage.py test --parallel 4 --noinput

  app:
    runs-on: ubuntu-latest
    timeout-minutes: 20
    defaults:
      run:
        working-directory: frontend
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
          cache: npm
          cache-dependency-path: frontend/package-lock.json
      - run: npm ci
      # Expo writes this on `expo start` and it is gitignored,
      # so a fresh checkout doesn't have it.
      - run: printf '/// <reference types="expo/types" />\n' > expo-env.d.ts
      - run: npm run typecheck
      - run: npx jest --ci

Hai job chạy song song. Trong 35 lần chạy thành công tính đến giờ, trung vị của job ứng dụng là khoảng bảy phút, còn job Python là khoảng mười hai phút rưỡi.

Khối services: chính là chỗ tệp Compose đã chuyển tới, phần sau sẽ nói rõ. Môi trường chỉ có vài biến và một cờ. Mọi thứ còn lại đều rơi về giá trị mặc định cho môi trường phát triển mà lập trình viên có được khi chạy docker compose up, nên bộ kiểm thử không cần bí mật (secret) nào. Để chắc chắn, tôi đã chạy thử một phần bộ kiểm thử với đúng môi trường đó và không có gì khác.

CI chạy cùng trình thông dịch với laptop của tôi và với image production, tức là bản Python 3.15.0 do chính uv dựng, vì uv sync đọc .python-version và tải về đúng bản đó. (Tệp thật của tôi còn truyền cho setup-uv một tham số python-version-file, thật ra chẳng làm gì cả: setup-uv v6 không có tham số nào như vậy, và lần chạy nào cũng kèm một cảnh báo nói đúng điều đó. Viết bài này tôi mới để ý.)

Việc dùng chung trình thông dịch đã chứng minh giá trị chỉ tám ngày sau khi workflow ra đời. Ngày 19 tháng 10, tôi bật trình biên dịch JIT của 3.15, và ngay lần chạy đầu tiên có JIT, một bài kiểm thử đã thất bại: một câu yield from rất bình thường, nằm trên đoạn code mà lần lưu dữ liệu nào của ứng dụng cũng đi qua, lại ném ra AttributeError: 'list' object has no attribute 'send'. Cùng commit đó mà tắt JIT thì qua. Máy Mac của tôi là arm64 nên chưa bao giờ gặp lỗi này; còn máy chạy CI (runner) là x86_64, giống các máy production. JIT giờ đã được tắt lại, cả trong CI lẫn trong Dockerfile, và lỗi này chưa bao giờ lọt lên production. Đó là lỗi python/cpython#155823, đã được sửa ở upstream vào ngày 13 tháng 10, sau khi 3.15.0 phát hành.

Thật ra ngay lần chạy đầu tiên cũng đã thất bại, nhưng vì một lý do tẻ nhạt hơn. Expo tạo tệp expo-env.d.ts khi bạn chạy expo start, mà tệp này lại nằm trong gitignore. Vì vậy bản làm việc nào tôi từng dùng cũng có nó, còn một bản checkout mới tinh thì không. TypeScript báo năm lỗi chưa từng xuất hiện trên máy tôi. Bước tạo tệp đó chính là cách sửa.

concurrency sẽ hủy lần chạy cũ khi có một lần push mới hơn lên cùng nhánh. Cả mười hai lần chạy bị hủy tính đến giờ đều kết thúc theo cách này. Một hook trước commit (pre-commit) chạy công cụ lint, và chạy thêm bộ kiểm tra kiểu khi có tệp Python hoặc TypeScript được stage, nên phần lớn lỗi không đi được tới lúc push.

Tệp Docker Compose đã đi đâu

#

Đây là phần trong tệp docker-compose.yml của ứng dụng mà CI quan tâm, viết lại dưới dạng ví dụ. Tệp thật còn nhiều dịch vụ hơn và nhiều biến môi trường hơn hẳn.

services:
  valkey:
    image: valkey/valkey:8-alpine
    ports:
      - "6379:6379"

  # Host port 55432, not 5432, so it can't collide with a local Postgres.
  postgres:
    image: postgres:17-alpine
    environment:
      - POSTGRES_USER=myapp
      - POSTGRES_PASSWORD=myapp
      - POSTGRES_DB=myapp
    ports:
      - "55432:5432"
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U myapp -d myapp"]
      interval: 5s
      retries: 10

  api:
    build: .
    command: python manage.py runserver 0.0.0.0:8000
    volumes:
      - .:/app
    ports:
      - "8000:8000"
    environment:
      - DATABASE_URL=postgresql://myapp:myapp@postgres:5432/myapp
      - REDIS_URL=redis://valkey:6379
    depends_on:
      postgres:
        condition: service_healthy
      valkey:
        condition: service_started

volumes:
  postgres_data:

Đặt nó cạnh khối services: trong checks.yml thì thấy đó là cùng hai image: Postgres 17 (ở đây là bản Alpine, trong CI là bản Debian) và valkey/valkey:8-alpine. Quan hệ giữa hai bên bây giờ là vậy. Tệp Compose là thứ lập trình viên chạy; còn CI khai báo cùng các image đó dưới dạng service container, rồi chạy thẳng trên runner đúng những lệnh mà lập trình viên vẫn chạy, uv run … và npm run ….

So với bài năm 2024, phần tôi quan tâm nhất vẫn đứng vững: công cụ CI vẫn mỏng, và các bước kiểm tra lẫn triển khai đều là những lệnh tôi tự chạy được. Thứ không trụ lại được là để CI gọi Compose.

CI của ứng dụng hoàn toàn không dựng Docker image. Image được dựng đúng một lần, lúc triển khai, trên máy dựng (builder) của Fly, còn CI chỉ cần trả lời code có ổn không, và khi bộ công cụ đã có sẵn trong bộ nhớ đệm (cache) thì việc đó chỉ tốn sáu giây cài đặt. Ngoài ra, tệp Compose còn bind-mount bản làm việc và nạp dữ liệu mẫu, những việc một lần chạy kiểm thử không nên làm. Vậy nên CI sẽ cần một tệp Compose riêng, tức là một bản mô tả thứ hai cho cùng các dịch vụ, phải giữ cho khớp nhau bằng tay.

Thêm nữa, ví dụ năm 2024 có một lỗi mà lúc đó tôi không để ý. docker compose build chỉ dựng image, chứ không bao giờ chạy command của dịch vụ. Thế nên lệnh npm test trong tệp đó chưa từng chạy trong CI, và workflow vẫn xanh dù kiểm thử có qua hay không.

Rủi ro mà bài đó lo nhất, tức là đổi nhà cung cấp CI, rốt cuộc chưa bao giờ xảy ra. Cuộc chuyển dịch thật sự lại diễn ra ở đầu bên kia: blog này và trang của khách hàng kia đã đổi nơi lưu trữ sang Cloudflare Pages, và với blog thì chỉ cần viết mới một workflow dài 45 dòng, vì khâu dựng vốn đã chỉ là một lệnh. Còn cái workflow ba trăm dòng mà tôi từng cảnh báo? Tôi có đúng một cái, của pyhtml2text. Nó dài vì wheel phải được dựng trên runner Linux, macOS và Windows, mỗi loại cho nhiều kiến trúc, và cũng vì vậy mà đây là việc duy nhất mà YAML riêng của nền tảng là công cụ đúng.

Bộ nhớ đệm: đọc thời gian từng bước trước đã

#

GitHub ghi lại thời gian của từng bước, và gh api repos/<owner>/<repo>/actions/runs/<run-id>/jobs sẽ trả về cho bạn. Đây là số liệu từ lần chạy thành công gần nhất của ứng dụng, ngày 20 tháng 10:

Cả hai bộ nhớ đệm cho thư viện phụ thuộc đều đang bật, và cả hai đều là phần rẻ. Bộ nhớ đệm uv mà GitHub giữ cho kho này chỉ khoảng 200 KB, vì setup-uv dọn đi những gì uv chỉ cần tải lại là xong; còn của npm thì gần 400 MB. Thời gian nằm ở bộ kiểm thử, mà bộ kiểm thử thì đã chạy song song bốn luồng rồi. Muốn chạy nhanh hơn, tôi sẽ sửa bộ kiểm thử chứ không phải bộ nhớ đệm.

Blog thì ngược lại. Ảnh đã được Hugo xử lý nằm trong thư mục resources/_gen vốn bị gitignore, nên runner mới nào cũng phải mã hóa lại toàn bộ ảnh bìa, ảnh trong bài và ảnh giữ chỗ. Workflow ở phía dưới khôi phục chúng bằng actions/cache, với khóa là mã băm của chính các bức ảnh; nếu khóa không khớp thì dùng bản cache cũ mới nhất, vì Hugo chỉ xử lý phần còn thiếu. Trong tám lần chạy cuối cùng trước khi có cache, bước dựng mất từ 33 đến 76 giây; trong 26 lần kể từ đó là 6 đến 20 giây, chỉ một lần ngoại lệ là 94 giây, dù chính commit đó còn thêm ảnh giữ chỗ và một cỡ thẻ thứ hai.

Image của ứng dụng được dựng trên builder của Fly: các tệp khai báo thư viện phụ thuộc được chép vào trước code, còn bộ nhớ đệm tải về của uv nằm trong một cache mount của BuildKit (RUN --mount=type=cache,target=/root/.cache/uv). Nhưng cải thiện lớn nhất ở đây lại không phải là bộ nhớ đệm. Tệp .dockerignore cũ là danh sách chặn (blocklist), và nó bỏ sót một thư mục chứa các git worktree phụ, mỗi worktree lại có thư viện phụ thuộc và sản phẩm dựng của riêng nó. Kết quả là 7,7 GB với 277.000 tệp bị đẩy lên builder mỗi lần triển khai. Viết lại thành danh sách cho phép (allowlist), ngữ cảnh dựng giờ chỉ còn khoảng 40 MB. Một ví dụ cho cách làm này:

# Exclude everything, then let back in only what the Dockerfile COPYs.
*

!pyproject.toml
!uv.lock
!manage.py
!myapp
!static

# Rules match the whole relative path and the last match wins,
# so these re-excludes apply inside the allowed directories too.
**/__pycache__/
**/*.pyc
**/.DS_Store
**/*.log

Bí mật, đặt ở càng ít chỗ càng tốt

#

Bí mật nằm ở ba nơi. Bí mật của GitHub Actions dành cho những việc workflow làm, và hai kho Hugo mỗi kho chỉ có đúng một cái, CLOUDFLARE_API_TOKEN. Bí mật của Fly là cấu hình lúc chạy của ứng dụng, được đặt bằng flyctl secrets set, và không bao giờ đi qua Actions. Cuối cùng là tệp .env bị gitignore trên laptop của tôi, chứa token mà script triển khai dùng để xóa cache của Cloudflare.

PyPI thì hoàn toàn không cần bí mật. pyhtml2text dùng cơ chế trusted publishing: PyPI chấp nhận token OIDC ngắn hạn mà GitHub cấp cho workflow, nên job phát hành chỉ xin quyền id-token: write, và trang bí mật của kho thì trống trơn. Không có gì để rò rỉ, cũng không có gì phải xoay vòng.

Token chỉ được cấp đúng quyền cần thiết. Token Fly của ứng dụng trên GitHub phục vụ một bước kiểm tra định kỳ chỉ liệt kê máy, nên nó được tạo bằng fly tokens create readonly. Các lần triển khai lên Pages chỉ xin contents: read và deployments: write, không hơn.

Dữ liệu đầu vào luôn đi qua env:, không bao giờ nhét thẳng vào script. Workflow OTA nhận ghi chú phát hành dạng văn bản tự do. Nếu viết ${{ inputs.notes }} ngay trong run:, đoạn văn bản sẽ được dán thẳng vào script trước khi bash đọc, nên một ghi chú có dấu nháy và dấu chấm phẩy sẽ biến thành code. Truyền qua biến môi trường thì nó vẫn chỉ là dữ liệu. Một ví dụ cho cách làm này:

      - name: Publish
        env:
          OTA_API_TOKEN: ${{ secrets.OTA_API_TOKEN }}
          INPUT_PLATFORM: ${{ inputs.platform }}
          INPUT_ROLLOUT: ${{ inputs.rollout }}
          INPUT_NOTES: ${{ inputs.notes }}
        run: |
          args=("$INPUT_PLATFORM")
          [ -n "$INPUT_ROLLOUT" ] && args+=(--rollout "$INPUT_ROLLOUT")
          [ -n "$INPUT_NOTES" ] && args+=(--notes "$INPUT_NOTES")
          ./scripts/publish-ota.sh "${args[@]}"

Có những khóa tôi để hẳn bên ngoài GitHub. Một bản báo cáo định kỳ cần một khóa có quyền quản trị phần đăng nhập của ứng dụng, nên nó đã chuyển từ một workflow định kỳ sang một tác vụ định kỳ trên máy Mac của tôi. Workflow vẫn còn đó làm phương án dự phòng chạy tay, và bỏ qua những mục cần đến khóa đó.

Triển khai: mỗi lần push, bằng script, và theo tag

#

Các trang Hugo được triển khai mỗi lần push

#

Đây là phiên bản ví dụ của workflow cho blog, đã lược bỏ bước tạo dự án Pages ở lần chạy đầu tiên:

name: Deploy to Cloudflare Pages

on:
  push:
  workflow_dispatch:

env:
  HUGO_VERSION: "0.165.0"
  PAGES_PROJECT: my-site

concurrency:
  group: deploy-${{ github.ref }}
  cancel-in-progress: true

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      deployments: write
    steps:
      - uses: actions/checkout@v7
        with:
          submodules: true

      - uses: peaceiris/actions-hugo@v3
        with:
          hugo-version: ${{ env.HUGO_VERSION }}
          extended: true

      # Processed images are gitignored; restore them so Hugo only
      # re-encodes what is new. An older cache still helps.
      - uses: actions/cache@v6
        with:
          path: resources/_gen
          key: hugo-resources-${{ hashFiles('content/**/*.jpg', 'content/**/*.png', 'assets/img/**') }}
          restore-keys: |
            hugo-resources-

      # A multilingual site has no root 404.html; without one, Pages
      # answers unknown paths with index.html and a 200.
      - name: Build
        run: |
          hugo --gc
          cp public/en/404.html public/404.html

      # ...

      - name: Deploy
        uses: cloudflare/wrangler-action@v4
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ vars.CLOUDFLARE_ACCOUNT_ID }}
          command: pages deploy public --project-name=${{ env.PAGES_PROJECT }} --branch=${{ github.ref_name }}

--branch=${{ github.ref_name }} làm cho main thành production và cho mọi nhánh khác một URL xem trước. Workflow cho trang của khách hàng có cùng cấu trúc, chỉ thêm một dòng rm -rf public trước khi dựng, vì bên đó thư mục public/ được commit, nếu không thì các trang đã xóa sẽ cứ nằm lại trong bản tải lên.

Phiên bản Hugo chỉ được ghim ở đây, không ở đâu khác. Tháng 10, một lần cập nhật của trình quản lý gói đã nâng Hugo trên laptop của tôi lên 0.168, cao hơn một bậc so với bản mới nhất mà theme hỗ trợ. Các lần triển khai vẫn ở 0.165 và chẳng hề hấn gì.

Và bước dựng chính là bài kiểm thử. Ngày 14 tháng 9, bản triển khai xem trước của một nhánh thất bại ba lần liên tiếp: một bài viết trên nhánh đó dùng ref của Hugo để liên kết tới một bài vẫn còn là bản nháp. CI dựng đúng như production dựng, tức là bỏ bản nháp ra, nên liên kết trỏ vào hư không và Hugo dừng lại với lỗi REF_NOT_FOUND. Trong lúc đó, main vẫn triển khai bình thường.

API của ứng dụng được triển khai bằng script

#

Phần cốt lõi của script triển khai, viết dưới dạng ví dụ:

IMAGE_LABEL="deploy-$(git rev-parse --short HEAD)-$(date +%Y%m%d%H%M%S)"

# Build first, then wake a spare machine, then roll out exactly that image.
flyctl deploy --config fly.toml --build-only --push --image-label "$IMAGE_LABEL"
curl -fsS --retry 5 https://myapp.fly.dev/health > /dev/null
flyctl deploy --config fly.toml --image "registry.fly.io/myapp:$IMAGE_LABEL"

Và các dòng tương ứng trong fly.toml:

[deploy]
  # max_unavailable only counts machines that are running,
  # which is why the script wakes one first.
  strategy = "rolling"
  max_unavailable = 1

Image được dựng đúng một lần, đẩy lên registry của Fly với một nhãn ghép từ commit và thời điểm, rồi được triển khai theo đúng nhãn đó, nên thứ được tung ra chính xác là thứ đã được dựng.

Thứ giúp triển khai không gián đoạn (zero-downtime) là việc đánh thức một máy dự phòng trước. max_unavailable = 1 chỉ đếm những máy đang chạy, mà ứng dụng lại không giữ máy nào chạy khi rảnh (một máy đang tạm dừng chỉ mất khoảng một giây để tỉnh lại). Vì vậy, trước đây cái máy duy nhất đang thức bị thay cùng đợt với các máy đang ngủ, và đằng sau nó không còn máy nào sẵn sàng. Ngày 28 tháng 9, tôi cho một đầu dò gửi yêu cầu liên tục tới origin: khi chạy flyctl deploy trơn thì có 7 lần hết thời gian chờ và một khoảng trống 7,3 giây, còn với script triển khai, vốn dựng trước và có sẵn một máy đang thức trước khi bắt đầu tung ra, thì không có lỗi nào trong 2.514 yêu cầu.

Phần còn lại của script đánh dấu lần triển khai trên kênh chat của đội, nơi các cảnh báo lỗi gửi về, để khi lỗi dồn dập thì có thể đối chiếu với thứ vừa thay đổi, rồi xóa cache Cloudflare và làm nóng các máy. Giao diện web thì hoàn toàn không đi qua image; chuyện đó tôi đã viết trong Triển khai frontend và backend riêng biệt, không cần triển khai lại API.

Migration không phải là một bước trong quy trình. release_command của Fly bị treo trong trường hợp của tôi, nên máy đầu tiên khởi động với image mới sẽ giữ khóa và chạy migration, trong khi các máy khác chờ. Vì thế, migration nào cũng phải tương thích với code vẫn đang chạy: thêm cột ở lần triển khai này, ngừng dùng nó ở lần sau, và xóa nó ở lần thứ ba.

Script này không có chỗ nào bắt buộc phải là laptop của tôi, nhưng có vài tệp chỉ nằm trên máy đang giữ nó ở đó: thông tin đăng nhập Cloudflare, và một bản ghi về thứ đã được triển khai lần gần nhất, thứ mà một runner mới tinh sẽ không có. Nó còn triển khai cả những thay đổi chưa commit, và có báo điều đó trên kênh chat, trong khi script phát hành web thì từ chối một cây làm việc chưa sạch.

Trong bài Môi trường xem trước cho từng nhánh, tôi viết rằng làm những việc này bằng tay thì ổn khi chỉ có một mình bạn làm, nhưng từ lập trình viên thứ hai trở đi thì nó phải xảy ra vì có gì đó xảy ra trong git. Ứng dụng vẫn chỉ có một lập trình viên. Các workflow môi trường theo nhánh trong bài đó vẫn nằm trên chính nhánh mà tôi đã dựng chúng.

Workflow OTA chỉ chạy tay, vì việc phát hành phải là một quyết định, và vì dịch vụ cập nhật từ chối bản phát hành mới khi đang có một đợt tung ra từng phần (partial rollout) còn mở, nên nếu kích hoạt theo push thì đợt canary nào cũng sẽ vướng. Workflow này chưa từng chạy lần nào. Mọi bản cập nhật OTA cho đến nay đều được đẩy đi từ laptop của tôi, qua chính script mà workflow gọi. Lý do nên giữ workflow mỏng gói gọn trong một câu: phát hành bắt đầu bằng cách nào thì cũng là cùng một script.

pyhtml2text phát hành theo tag

#

Job phát hành, với tên gói đã được đổi thành tên chung chung:

  release:
    runs-on: ubuntu-latest
    if: ${{ startsWith(github.ref, 'refs/tags/') || github.event_name == 'workflow_dispatch' }}
    needs: [linux, macos, windows, sdist]
    environment:
      name: pypi
      url: https://pypi.org/p/mypackage
    permissions:
      id-token: write       # trusted publishing and signing
      contents: write
      attestations: write
    steps:
      - uses: actions/download-artifact@v8
      - uses: actions/attest@v4
        with:
          subject-path: 'wheels-*/*'
      - uses: astral-sh/setup-uv@v10
        if: ${{ startsWith(github.ref, 'refs/tags/') }}
        with:
          prune-cache: true
      - name: Publish to PyPI
        if: ${{ startsWith(github.ref, 'refs/tags/') }}
        run: uv publish --trusted-publishing always 'wheels-*/*'

Job phát hành chờ mọi job dựng xong, và chỉ khi có tag mới thật sự xuất bản; chạy tay thì chỉ dựng và tạo chứng thực (attestation) chứ không tải gì lên. actions/attest ghi lại workflow nào đã dựng từng wheel, còn uv publish --trusted-publishing always tải chúng lên bằng token OIDC thay vì mật khẩu. Bản thân gói thư viện này tôi đã viết trong Một pull request bị đóng, một bản fork và một gói PyPI.

Workflow định kỳ chỉ là “cố gắng hết sức”

#

Ứng dụng có một workflow chạy định kỳ, kiểm tra xem Fly có bật nhiều máy hơn mức cơ bản hay không, chuyện mà nếu không kiểm tra thì sẽ chỉ lộ ra trên hóa đơn. Nó cảnh báo bằng cách cố ý thất bại, vì GitHub sẽ gửi email cho chủ kho khi một lần chạy định kỳ thất bại.

Lịch được đặt là cron: '*/15 * * * *', tức 96 lần một ngày. Vậy mà trong hai tuần qua, mỗi ngày nó chỉ chạy từ ba đến tám lần, với khoảng cách trung vị giữa các lần chạy khoảng ba tiếng bốn mươi phút. Lời giải thích duy nhất trong tài liệu của GitHub là tải: lần chạy định kỳ có thể bị trễ khi Actions bận, và bị bỏ qua khi bận đến một mức nào đó. Với một đợt mở rộng quy mô kéo dài, vài tiếng là đủ. Còn với thứ gì cần báo trong vòng vài phút, cron của GitHub không phải là công cụ giám sát.

Những câu tôi sẽ hỏi về một quy trình CI/CD

#

Dù bạn đang dựng một quy trình mới hay xem lại quy trình đang có:

1. Nếu GitHub Actions ngừng hoạt động cả một ngày, bạn có còn phát hành được không? Nếu không, logic phát hành của bạn đang nằm trong YAML, và bài năm 2024 vẫn còn đúng.
2. CI có chạy cùng trình thông dịch, cùng kiến trúc CPU và cùng phiên bản chính của cơ sở dữ liệu với production không? CI của tôi bắt được một lỗi trình biên dịch chỉ vì runner và production đều là x86_64, còn laptop của tôi thì không.
3. Một bản checkout mới tinh có qua được không? Nếu không, thủ phạm thường là các tệp được sinh tự động và bị gitignore.
4. Thời gian của một lần chạy thật ra tiêu vào đâu? Hãy đọc thời gian từng bước trước khi thêm bộ nhớ đệm.
5. Mỗi bí mật đang nằm ở bao nhiêu chỗ, và nó có thật sự cần nằm trên GitHub không?

pip install pyhtml2text

from pyhtml2text import html2markdown

html = """<h2>Before you start</h2>
<p>Read the <a href="setup.html">setup guide</a> and <b>back up</b> your data.</p>
<img src="https://jared.lynskey.co.nz/img/diagram.png" alt="How it fits together">
<table><tr><th>Plan</th><th>Price</th></tr><tr><td>Basic</td><td>Free</td></tr></table>"""

print(html2markdown(html, base_url="https://example.com/docs/intro.html"))

## Before you start

Read the [setup guide](https://example.com/docs/setup.html) and **back up** your data.

![How it fits together](https://example.com/img/diagram.png)

| Plan | Price |
| --- | --- |
| Basic | Free |

Mọi chuyện bắt đầu từ một pull request gửi cho rust-html2text. Người bảo trì (maintainer) đã đóng nó vì nó được viết bằng LLM, nên pyhtml2text chạy trên một bản fork. Bài này kể chuyện đó diễn ra thế nào, bản fork và gói Python có gì, và tôi đã kiểm tra thế nào để chắc rằng Markdown đầu ra là đúng.

Vì sao tôi cần nó

#

Ứng dụng chợ kiêm cộng đồng mà tôi đang làm trả về Markdown thay vì HTML khi nhận Accept: text/markdown, dành cho các AI agent và client LLM không muốn phải lội qua thanh điều hướng và chân trang. Phần xử lý ở tầng edge tôi đã viết trong bài về crawler và bộ nhớ đệm. Những trang lấy từ dữ liệu của ứng dụng thì HTML chỉ là một vỏ JavaScript rỗng, nên Markdown được dựng thẳng từ dữ liệu. Phần còn lại là HTML tĩnh (trang giới thiệu, điều khoản pháp lý và blog), và phần đó thì phải chuyển đổi.

Vấn đề khi chuyển đổi nằm ở các liên kết. Một trang web tĩnh đầy những liên kết kiểu /en/posts/... và ../setup/. Trong trình duyệt thì không sao, vì trình duyệt biết chúng đến từ trang nào. Một agent đọc Markdown thì không có ngữ cảnh đó, nên nó không thể đi theo /login. Nó cần https://example.com/login.

Thư viện html2text viết bằng Python thuần có tuỳ chọn baseurl cho việc này, và lúc đầu tôi dùng nó. Nhưng nó chậm, và Markdown của nó có vài vấn đề mà tôi sẽ nói ở phần dưới. rust-html2text thì nhanh và được kiểm thử kỹ, nhưng lại không có cách nào phân giải liên kết.

Hỏi dự án gốc trước

#

Ngày 29 tháng 8, tôi mở issue #287, mô tả trường hợp sử dụng và hành vi tôi muốn: phân giải theo RFC 3986, giữ nguyên các URL tuyệt đối và các liên kết mailto:, data: và #fragment. Vài phút sau, tôi mở pull request #288. Nó thêm tuỳ chọn Config::base_url(...), và trong issue tôi có nói rằng đây chỉ là điểm khởi đầu, và tôi sẽ hiểu nếu người bảo trì muốn làm theo cách khác.

Ngày 11 tháng 10, người bảo trì đóng PR:

Thanks for the contribution, but I’m unable to accept this as it appears to be LLM generated. (I have now added a brief policy to the README.md - it wasn’t previously stated)

(Tạm dịch: “Cảm ơn bạn đã đóng góp, nhưng tôi không thể nhận cái này vì có vẻ nó được tạo bằng LLM. (Tôi vừa thêm một chính sách ngắn vào README.md, trước đây chưa có.)”)

và trả lời trong issue:

Hi - this is a reasonable feature request, thanks! I have closed the PR as it appears to be LLM-written which I can’t accept, but thanks for the attempt.

A short HTML sample and expected output would definitely help get the feature implemented!

(Tạm dịch: “Chào bạn, đây là một yêu cầu tính năng hợp lý, cảm ơn! Tôi đã đóng PR vì có vẻ nó được viết bằng LLM, điều mà tôi không thể chấp nhận, nhưng cảm ơn bạn đã thử. Một mẫu HTML ngắn kèm đầu ra mong muốn chắc chắn sẽ giúp tính năng này được hiện thực!”)

README giờ có chính sách này:

At this time, this project is not able to accept code contributions produced with generative AI/LLMs due to the uncertain copyright status.

(Tạm dịch: “Hiện tại, dự án này không thể nhận các đóng góp mã được tạo bằng AI tạo sinh/LLM, vì tình trạng bản quyền còn chưa rõ ràng.”)

Nhận định đó là đúng: tôi viết đoạn mã ấy bằng một trợ lý lập trình AI. Tôi cũng không nghĩ chính sách đó vô lý. Tình trạng bản quyền của đầu ra từ LLM chưa ngã ngũ, và người gánh rủi ro khi gộp nó vào một crate MIT mà nhiều dự án khác phụ thuộc là người bảo trì. Đó là dự án của họ, và câu trả lời rất lịch sự. Yêu cầu tính năng đó đến giờ vẫn còn mở.

Dù vậy, tôi vẫn cần tính năng này, và tranh cãi với người bảo trì về chính sách đóng góp của chính dự án họ không phải là cách hay để có nó. Vì thế tôi giữ thay đổi trên một bản fork rồi xây gói Python dựa trên đó, và cả hai đều ghi rõ rằng chúng không phải là bản gốc (upstream).

Bản fork có gì

#

Bản fork là nhánh pyhtml2text-perf trong bản fork rust-html2text của tôi. Tôi chỉ giữ ba commit nhỏ để nó luôn rebase gọn gàng lên dự án gốc (upstream). Commit chính là tùy chọn Config::base_url lấy từ PR: liên kết tương đối được phân giải theo RFC 3986 §5.3, và nếu không truyền base URL thì đầu ra giữ nguyên. Commit thứ hai khiến crate không còn dựng lại các quy tắc style mỗi lần được gọi, nhờ vậy một đoạn HTML ngắn giảm từ 7.3 µs xuống 5.6 µs. Với trang lớn thì chẳng đáng là bao, nhưng gọi vài nghìn lần thì cộng dồn lại cũng đáng kể. Commit thứ ba chỉ mở ra (export) những phần mà bộ chuyển Markdown ở dưới cần dùng từ crate.

Gói Python

#

pyhtml2text được xây bằng PyO3 và maturin, và có hai hàm:

from pyhtml2text import html2text, html2markdown

html2text(html, width=80, *, base_url=None, decorate=True, link_footnotes=True,
          table_borders=True, wrap_links=True, max_wrap_width=None, raw=False)

html2markdown(html, *, base_url=None)

html2text là bộ render văn bản thuần của rust-html2text, vốn được làm cho terminal và phần text/plain của email:

print(html2text('<p>Please <a href="https://jared.lynskey.co.nz/login">sign in</a> first.</p>',
                base_url="https://example.com/docs/page.html"))

Please [sign in][1] first.

[1]: https://example.com/login

Vài điểm về phần binding có thể không hiển nhiên:

• Cả hai hàm đều nhận str hoặc bytes UTF-8, nên bạn có thể truyền thẳng response.content mà không cần giải mã trước. Dữ liệu đầu vào được mượn (borrow), không bị sao chép.
• GIL được nhả ra trong lúc chuyển đổi. Từ đầu tới cuối đều là Rust thuần, nên các luồng (thread) chạy song song được trên nhiều nhân. Module cũng khai báo rằng nó không cần GIL, nên Python 3.14t bản free-threaded sẽ không bật GIL trở lại khi import module.
• Một panic sẽ trả về dưới dạng ValueError. Mặc định PyO3 ném PanicException, thứ mà except Exception không bắt được. Một web worker tưởng rằng mình đã xử lý hết lỗi chuyển đổi sẽ sập vì nó, nên phần binding bắt panic lại và ném ra dưới dạng ValueError.
• Có 30 wheel: wheel abi3 cho CPython 3.10 trở lên, cộng thêm wheel cho bản free-threaded 3.14t, trên Linux (glibc và musl), macOS và Windows, ở mọi kiến trúc mà CI của maturin build được. Vì vậy không ai cần cài bộ công cụ Rust để cài gói này.

Làm cho nó nhanh

#

Bản 0.2.0 nhanh hơn 0.1.0 từ 1.5 đến 1.7 lần trên trang thật và nhanh gấp đôi với đoạn HTML ngắn, mà đầu ra vẫn giống hệt đến từng byte. Phần lớn là nhờ tối ưu hóa dựa trên profile (profile-guided optimisation, PGO): CI build một wheel có gắn đo đạc (instrumented), chạy nó qua một bộ dữ liệu huấn luyện gồm các trang tài liệu và RFC, rồi dùng profile thu được để build wheel thật. Kết quả là nhanh hơn khoảng 25% trên những trang không nằm trong bộ huấn luyện, và chỉ áp dụng trên các nền tảng mà CI chạy được bản build đo đạc một cách native. Phần còn lại đến từ việc chuyển sang bộ cấp phát bộ nhớ mimalloc, vốn xử lý hàng loạt lần cấp phát nhỏ tốt hơn hẳn, và từ thay đổi về quy tắc style trong bản fork.

Để chắc chắn việc tăng tốc không làm thay đổi gì, tôi băm (hash) đầu ra của một tập trang thật với mọi tổ hợp tùy chọn, kèm các trường hợp biên như đầu vào rỗng hay lồng nhau cực sâu. Mỗi thay đổi đều phải giữ nguyên toàn bộ giá trị băm.

Đây là thời gian trung vị trên một máy Mac Apple Silicon, khi chuyển sang Markdown:

Và khi chuyển sang văn bản thuần:

HTML lồng nhau rất sâu, và một bản vá cho html5ever

#

Chẳng ai tự tay viết 40,000 danh sách lồng vào nhau. Nhưng nếu bạn chuyển đổi những trang mà mình không viết ra, sớm muộn gì cũng sẽ có thứ độc hại hoặc bị hỏng gửi đến bạn một trang như thế. Với parser nguyên bản, 40,000 cặp <ul><li> lồng nhau mất 6 giây để phân tích, tức là một worker bị kẹt cứng chỉ vì một yêu cầu.

Nguyên nhân nằm ở html5ever, bộ phân tích HTML5 mà rust-html2text dùng. Phần lớn thẻ mở cấp khối (block-level) phải kiểm tra xem có phần tử <p> nào đang mở “trong button scope” hay không, và html5ever trả lời câu đó bằng cách duyệt toàn bộ ngăn xếp các phần tử đang mở. Lồng càng sâu thì mỗi thẻ càng tốn thời gian, nên tổng thời gian tăng theo bình phương độ sâu.

Gói này đi kèm html5ever 0.39.0 với đúng một bản vá: câu trả lời được cập nhật sẵn mỗi khi một phần tử được mở hoặc đóng, nên việc kiểm tra không còn phụ thuộc vào độ sâu nữa. Cùng tài liệu đó giờ chỉ mất 0.14 giây để phân tích. Để chắc bản vá không làm thay đổi gì khác, tôi so sánh DOM do bộ phân tích gốc và bản đã vá tạo ra trên toàn bộ bài kiểm thử dựng cây (tree-construction) của html5lib, khoảng 20 trang thật và 300,000 tài liệu tag soup ngẫu nhiên, và tất cả đều giống hệt nhau.

Vì cùng lý do đó, bộ chuyển Markdown cũng có giới hạn riêng. Không đầu vào nào có thể làm tràn ngăn xếp của luồng; blockquote và danh sách sẽ ngừng thụt lề khi vượt quá 32 cấp, để đầu ra không phình theo bình phương; và một bảng mà lưới sau khi trải ra vượt quá 100,000 ô sẽ chỉ được ghi ra nội dung các ô.

html2markdown

#

Phiên bản 0.3.0 thêm html2markdown, và phần lớn công sức trong gói này dồn vào nó. Bộ render của rust-html2text tạo ra văn bản trông giống Markdown, nhưng nó được ngắt dòng cho terminal và không được làm ra để phân tích lại. Vì vậy html2markdown chỉ mượn phần phân tích cú pháp, còn đầu ra thì tự ghi theo CommonMark, cộng thêm bảng pipe và ~~strikethrough~~ theo kiểu GitHub:

• Tiêu đề #, gạch đầu dòng -, _emphasis_ và **strong**.
• Liên kết và hình ảnh nội dòng (inline), được chuyển thành địa chỉ tuyệt đối khi có base_url. Một liên kết chỉ chứa mỗi biểu tượng (icon) sẽ dùng aria-label hoặc title của nó làm văn bản.
• Khối mã có rào (fenced code block), gắn tên ngôn ngữ khi trang có ghi (class="language-python").
• Bảng pipe. Ô trải nhiều hàng hoặc nhiều cột trở thành các ô trống, bảng không có hàng tiêu đề sẽ được thêm một hàng tiêu đề trống, và bảng dùng để dàn trang được ghi ra thành các đoạn văn.
• Không ngắt dòng. Nội dung ẩn (hidden, aria-hidden, display: none), script, style và các điều khiển biểu mẫu (form control) bị bỏ qua.

Chỉ escape những gì cần thiết

#

Một số bộ chuyển HTML sang Markdown escape mọi ký tự có thể là cú pháp Markdown. Ví dụ, markdownify mặc định escape mọi _ và *. Đầu ra vẫn đúng, nhưng đầy những snake\_case và 5 \* 3, khó đọc hơn với con người và tốn token vô ích với một mô hình. pyhtml2text chỉ escape một ký tự ở những chỗ mà nếu không escape, một parser CommonMark sẽ đọc nó thành cú pháp:

html2markdown('<p>Use <code>snake_case</code>, 5 * 3, $5 and '
              '<a href="../setup.html">setup</a></p>',
              base_url="https://example.com/docs/intro.html")

Use `snake_case`, 5 * 3, $5 and [setup](https://example.com/setup.html)

In đậm trước một tiểu từ tiếng Hàn

#

Vấn đề này đến từ chính các trang trong ứng dụng của tôi. Trong tiếng Hàn, tiểu từ ngữ pháp (particle, chẳng hạn 의 có nghĩa “của”) được viết dính liền ngay sau danh từ, không có dấu cách. Vì vậy một thuật ngữ in đậm có chứa dấu ngoặc trông như thế này:

<p><b>타이타닉(Titanic)</b>의 감독</p>

Cách viết Markdown hiển nhiên nhất là **타이타닉(Titanic)**의, cũng chính là thứ markdownify tạo ra, và nó không hoạt động. Quy tắc flanking của CommonMark không cho ** đóng lại ngay sau một dấu câu, trừ khi theo sau nó là dấu cách hoặc thêm một dấu câu nữa. Mà 의 là một chữ cái, nên các dấu sao bị giữ nguyên dưới dạng ký tự thường. html2text bản Python thuần né chuyện này bằng cách chèn thêm một dấu cách:

**타이타닉(Titanic)** 의 감독

Cách đó hiển thị được chữ in đậm, nhưng làm thay đổi tiếng Hàn. Tiểu từ giờ bị tách ra thành một từ riêng, mà trong tiếng Hàn thì đó là lỗi chính tả, giống như viết “của” tách khỏi một từ mà lẽ ra nó phải dính vào. pyhtml2text thay vào đó đưa dấu câu ra ngoài cặp dấu in đậm:

**타이타닉(Titanic**)의 감독

Dấu ngoặc đóng không còn được in đậm nữa, nhưng phần nhấn mạnh vẫn được phân tích đúng và mọi ký tự của bản gốc đều được giữ lại. Điều tương tự cũng áp dụng cho tiếng Nhật và tiếng Trung, và cho bất kỳ ngôn ngữ nào không đặt dấu cách trước phần đi theo sau.

Kiểm tra đầu ra bằng cách đọc ngược lại

#

Tôi không tin một bộ chuyển đổi chỉ vì nó qua hết bài kiểm thử đơn vị (unit test), bởi lỗi trong đầu ra Markdown thường nằm ở những tổ hợp mà chẳng ai nghĩ tới để viết kiểm thử. Vì vậy đầu ra được kiểm tra bằng cách đọc ngược lại.

Trong lúc chuyển đổi, mỗi đoạn văn được phân tích lại theo CommonMark để xác nhận phần nhấn mạnh được đọc đúng như ý. Nếu không đúng, đoạn đó được viết lại bằng kiểu nhấn mạnh còn lại (* thay cho _, hoặc ngược lại); nếu cả hai đều không được thì giữ lại chữ, liên kết và mã, chỉ bỏ định dạng, để không mất chữ nào. Bộ kiểm thử thì chạy một vòng khứ hồi (round trip) qua một bộ phân tích Markdown khác, rồi so từng chữ hiển thị, đích liên kết và nguồn ảnh với HTML gốc. Chữ bị cú pháp chưa escape “nuốt” mất, liên kết không phân tích được hay một dấu * lạc chỗ đều hiện ra thành chỗ khác biệt. Nó chạy trên các trang thật và hàng chục nghìn tài liệu ngẫu nhiên, và khi có lỗi thì thu nhỏ tài liệu đó về một trường hợp tối giản.

Chạy thật

#

Phần thương lượng markdown (markdown negotiation) trong ứng dụng của tôi chuyển từ html2text bản Python thuần sang pyhtml2text ngay trong ngày 0.3.0 ra mắt. Trên một trang hướng dẫn, thời gian chuyển đổi giảm từ 4.2 ms xuống 0.36 ms, nhanh hơn khoảng 12 lần. Liên kết đều là tuyệt đối, bảng là bảng pipe thật sự, còn chữ in đậm tiếng Hàn vẫn giữ tiểu từ dính liền. Các wheel abi3 vốn đã hỗ trợ Python 3.14 trên x86_64 và arm64, nên container image không cần cài thêm gì để dùng nó.

Ghi công, và nơi báo lỗi

#

Phần render văn bản thuần là rust-html2text của Chris Emerson, theo giấy phép MIT. pyhtml2text bổ sung một bản fork của nó, một bản html5ever đã vá (MIT/Apache-2.0) và bộ chuyển đổi Markdown. Gói này không liên kết với cũng như không được bảo trợ bởi dự án nào trong hai dự án đó, nên vui lòng báo lỗi tại trang issue của pyhtml2text, đừng báo lên dự án gốc. Lỗi nào trong mã này thì tôi là người phải sửa, và những người bảo trì dự án gốc không nên phải nhận báo cáo về đoạn mã mà họ đã từ chối nhận.

Nếu bạn đang chuyển đổi HTML bằng Python, nhất là để cho một mô hình đọc, hãy thử nó:

pip install pyhtml2text

Mã nguồn có trên GitHub, và changelog liệt kê mọi thay đổi từ 0.1.0 đến 0.3.0.

Hiện tại, với vai trò là một lập trình viên độc lập (solo developer), tôi đang vận hành đồng thời hai sản phẩm:

• một ứng dụng ước tính và báo giá tại hiện trường (field estimation) dành cho các kỹ thuật viên/thợ dịch vụ, giúp họ tính chi phí và báo giá công việc ngay tại chỗ;
• và một ứng dụng chợ mua bán kiêm cộng đồng (marketplace), với các tính năng như đăng tin và nhắn tin thời gian thực.

Hai sản phẩm khác nhau, nhóm người dùng cũng khác nhau, nhưng bộ công nghệ (tech stack) gần như giống hệt nhau — và cả hai đều đang chạy hoàn toàn trên các máy shared-cpu-1x, gói rẻ nhất mà Fly.io cung cấp.

Đây là một giới hạn được tôi chủ động lựa chọn.

Thay vì chọn cấu hình máy chủ theo mức tải đỉnh (peak load), tôi cố gắng khai thác tối đa hiệu năng của một máy nhỏ, đo chính xác ngưỡng mà hệ thống bắt đầu gặp điểm nghẽn (bottleneck) hoặc sụp đổ khi tải cao, rồi để bộ tự động co giãn (autoscaler) của Fly.io tự mở rộng hoặc thu hẹp theo chiều ngang (scale out / scale in), thêm hoặc bớt máy dựa trên chính ngưỡng đã đo đó.

Bài viết này sẽ đi vào các kỹ thuật tối ưu hóa giúp mô hình đó khả thi, các số liệu kiểm thử tải (load testing) dùng để xác định ngưỡng mở rộng (scaling threshold), và cách việc tăng, giảm số máy thực tế diễn ra trên Fly.io.

Triết lý: đo một máy, rồi nhân lên

#

Chiến lược mở rộng quy mô của cả hai ứng dụng đều gồm ba bước giống nhau:

1. Tối ưu một máy nhỏ cho nhanh nhất trong khả năng hợp lý.
2. Kiểm thử tải cho đến khi máy gãy, rồi ghi lại số yêu cầu đồng thời (concurrency) mà tại đó độ trễ (latency) bắt đầu vọt lên.
3. Cấu hình bộ tự động co giãn của Fly để bật máy thứ hai ngay trước điểm đó, và dừng các máy đang rảnh khi lưu lượng truy cập (traffic) giảm.

Khi đó, năng lực xử lý tăng gần như tuyến tính theo số máy, còn chi phí nền chỉ là một máy ảo (VM) nhỏ cho mỗi ứng dụng. Mọi thứ trong phần còn lại của bài đều phục vụ một trong ba bước này.

Tối ưu cho một máy nhỏ chạy nhanh

#

Granian: WSGI cho API, ASGI với uvloop cho WebSocket

#

Phía máy chủ (backend) của cả hai sản phẩm đều là Django 6 + Django REST Framework. API chạy trên Granian, một máy chủ viết bằng Rust, nhưng dùng WSGI với nhóm luồng chặn (blocking thread pool) chứ không phải ASGI:

granian --interface wsgi myapp.wsgi:application \
    --workers 1 --blocking-threads 16 \
    --workers-max-rss 1400 \
    --workers-kill-timeout 15 --respawn-failed-workers

Lúc đầu tôi dùng --interface asgi --loop uvloop, và đó là một quyết định sai. Mọi view HTTP trong hai ứng dụng này đều là đồng bộ (sync), mà trình xử lý ASGI của Django lại chạy view đồng bộ ở chế độ thread_sensitive, tức mỗi tiến trình worker chỉ xử lý được một view tại một thời điểm. Kết quả là với ASGI, mỗi worker chỉ xử lý được khoảng một yêu cầu đồng thời, lại còn phải nạp nguyên bộ asyncio/uvloop/Channels vào RAM mà chẳng được lợi gì. Còn WSGI với --blocking-threads thì chạy chính những view đồng bộ đó trong một nhóm luồng thực thụ: một worker × 16 luồng = 16 yêu cầu nặng về I/O chạy đồng thời (đọc cơ sở dữ liệu, tạo URL ký trước (presigned URL) cho S3), mà bộ nhớ thường trú lại còn thấp hơn bản bất đồng bộ.

Tại sao chỉ dùng một worker? Vì máy ảo là shared-cpu-1x, tức chỉ có một nhân. Thêm worker thứ hai cũng không chạy Python song song được trên một nhân (GIL cộng với chỉ một CPU), nhưng lại tốn thêm nguyên một tiến trình Django thường trú trong bộ nhớ; chính Granian cũng cảnh báo đúng chuyện này. Với các tác vụ nặng về I/O, mười sáu luồng trên một worker là mức trần thực tế của một máy 1 vCPU. Tham số --workers-max-rss 1400 sẽ khởi động lại worker nếu nó phình quá giới hạn bộ nhớ, nên nếu một tác vụ tạo PDF hay xử lý ảnh chạy mất kiểm soát thì worker sẽ được thay mới, thay vì kéo cả máy đến chỗ cạn bộ nhớ (OOM).

WebSocket được tách ra chạy trong một tiến trình Granian riêng: một ứng dụng ASGI dùng uvloop và --ws, với một worker chuyên giữ các kết nối dài hạn. Phần API đồng bộ hoàn toàn không cần tới ASGI: khi một view cần đẩy dữ liệu xuống socket, nó gọi async_to_sync(channel_layer.group_send) qua Redis, và thông điệp vẫn đến được tiến trình WebSocket. Hai máy chủ, mỗi cái chạy đúng giao diện (interface) mà nó làm tốt nhất. Docker trên máy cục bộ cũng chạy cùng nhóm luồng WSGI đó, nên khi kiểm thử, laptop của tôi mô phỏng khá sát một máy trong môi trường production.

Dùng Rust ở các đường xử lý nóng

#

Ở đường xử lý nóng (hot path) nào của Python mà có sẵn một thư viện viết bằng Rust thay thế được ngay, tôi đều dùng:

• orjson qua drf-orjson-renderer: mọi phản hồi của API đều được tuần tự hóa bằng Rust thay vì bộ mã hóa JSON của thư viện chuẩn.
• blurhash-rs: tạo ảnh giữ chỗ (placeholder) ngay lúc ảnh được tải lên.
• uuid-utils: sinh UUID bằng Rust.
• psycopg 3 (binary): trình điều khiển (driver) Postgres được tăng tốc bằng C.

Không thư viện nào trong số này làm thay đổi kiến trúc; chúng chỉ nâng mức trần của một vCPU lên, để bạn chưa phải thêm máy thứ hai sớm.

Loại bỏ những độ trễ ẩn

#

Cải thiện lớn nhất trong mã nguồn của cả hai ứng dụng không đến từ thuật toán nào cả, mà từ việc tái sử dụng kết nối. Trong nhóm luồng của Granian, mỗi luồng mới lại tạo một đối tượng client S3 của boto3 mới toanh, và endpoint nào trả về ảnh hay PDF cũng phải gánh chi phí đó. Tôi viết một lớp lưu trữ (storage) nhỏ tùy chỉnh để lưu đệm (cache) client theo từng tiến trình:

Thời gian tạo URL có chữ ký trên các luồng mới giảm từ ~150ms xuống ~1ms.

Với cơ sở dữ liệu cũng vậy: Postgres trên Fly nằm sau PgBouncer, nên ứng dụng chạy với conn_max_age=0 và để bộ gộp kết nối (pooler) lo phần tái sử dụng kết nối, kèm connect_timeout 5 giây để khi gặp kết nối SSL đã chết thì báo lỗi ngay, chứ không làm treo cả worker.

Đặt bộ nhớ đệm đúng chỗ đang thực sự nghẽn

#

Đợt kiểm thử tải phía chợ mua bán cho tôi một bài học đáng nhớ: mức trần nằm ở số kết nối Postgres, không phải CPU. Phần lớn lưu lượng duyệt tin đến từ người dùng ẩn danh, và nội dung họ xem giống hệt nhau. Khi tải lên cao, những truy vấn danh sách giống hệt nhau đó làm đầy nhóm kết nối, trong khi CPU vẫn ngồi chơi.

Cách sửa là thêm một lớp bộ nhớ đệm Redis cho các trang danh sách mà người dùng ẩn danh xem, và vô hiệu hóa bộ nhớ đệm bằng bộ đếm phiên bản theo từng không gian tên (namespace): mỗi thao tác ghi chỉ cần tăng một bộ đếm (O(1), không phải theo dõi từng khóa), thế là mọi trang đã lưu đệm của tài nguyên đó lập tức hết hiệu lực. Một thời gian sống (TTL) ngắn làm lưới an toàn cho những trường hợp bị sót. Trả trang duyệt tin thẳng từ Redis gỡ được đúng điểm nghẽn thật, và để cái máy nhỏ dành kết nối cơ sở dữ liệu cho người dùng đã đăng nhập.

Chạy tác vụ nền mà không cần trình trung gian

#

Cả hai ứng dụng đều dùng django-tasks-db, framework tác vụ của Django lưu hàng đợi trong cơ sở dữ liệu, thay cho Celery. Một tiến trình db_worker riêng liên tục thăm dò cơ sở dữ liệu để lấy việc: xử lý ảnh, tạo PDF, dịch máy, gửi nhắc nhở. Không cần trình trung gian thông điệp (broker), không phải dựng và giám sát thêm dịch vụ nào, và tiến trình API không bao giờ bị những việc nặng chặn lại. Worker còn kết nối thẳng tới Postgres, bỏ qua PgBouncer, vì các tác vụ chạy lâu không hợp với chế độ gộp kết nối theo giao dịch (transaction pooling).

Bộ nhớ: jemalloc và bộ nhớ hoán đổi để dự phòng

#

Xử lý ảnh và PDF làm bộ nhớ tăng vọt theo những cách mà khi tính toán cấu hình cho trạng thái ổn định bạn không lường trước được. Tôi dùng hai cách giảm thiểu rẻ tiền: nạp sẵn jemalloc trong Docker image để giảm phân mảnh bộ nhớ, và bật bộ nhớ hoán đổi (swap) trên mọi máy (2GB trên máy API, 1GB trên máy WebSocket), để khi bộ nhớ tăng vọt thì dữ liệu được đẩy xuống đĩa chứ tiến trình không bị hệ thống buộc dừng vì cạn bộ nhớ. Bộ nhớ hoán đổi không phải tính năng giúp tăng hiệu năng; nó là một khoản bảo hiểm, cho phép tôi giữ mức cấp phát bộ nhớ ở mức nhỏ.

Kiểm thử tải Django: tìm điểm gãy

#

Một ngưỡng chỉ đáng tin khi nó đã được đo thực tế. Mỗi dự án có bộ công cụ kiểm thử riêng:

• Ứng dụng báo giá tại hiện trường có một script kiểm thử sức chịu tải nhỏ viết bằng Python, chạy lần lượt qua các mức yêu cầu đồng thời và báo cáo số yêu cầu mỗi giây (RPS), p50/p95/p99 cùng tỉ lệ lỗi. Script chạy trên vài trăm bản ghi mẫu được sinh sẵn, để các endpoint danh sách được truy vấn trên khối lượng dữ liệu sát thực tế.
• Chợ mua bán dùng Locust với kiểu tải bậc thang, tăng từ 50 → 500 người dùng theo từng bậc 30 giây để tìm điểm bão hòa, với trọng số các endpoint khớp với lưu lượng thực tế (phần lớn là duyệt tin). Ngoài ra còn một bộ kiểm thử nhỏ hơn, tăng từ 5 → 50 người dùng ảo, chạy thẳng vào môi trường production với ngưỡng p95 < 2s.

Vài con số tiêu biểu từ lượt đo của ứng dụng báo giá tại hiện trường (một worker Granian × 16 luồng chặn, chạy Docker trên máy phát triển của tôi):

Còn con số quyết định mọi thứ khác đến từ đợt kiểm thử tải chợ mua bán trên một máy shared-cpu-1x duy nhất. Với bản ASGI cũ, đây là một bức tường cứng: các view đồng bộ bị xếp hàng tuần tự, chỉ còn khoảng ba suất xử lý (slot) dùng được, nên p95 giữ dưới 300ms cho đến khoảng 5 yêu cầu đồng thời, rồi sụp hẳn khi vượt ~8–10, vì mọi yêu cầu đều phải xếp hàng sau cái khóa thread-sensitive. Chính việc chuyển API sang nhóm luồng WSGI đã đẩy điểm gãy đó ra xa: 16 suất đồng thời thực sự trên mỗi máy thay vì ~3, và mức trần mới này là nền tảng cho toàn bộ cấu hình tự động co giãn.

Cơ chế co giãn trên Fly.io

#

Mô hình của Fly khá đơn giản: ứng dụng của bạn là một nhóm máy giống hệt nhau đứng sau một proxy, và proxy đếm tải trên từng máy. Bạn chỉ cần khai báo hai con số:

[http_service.concurrency]
  type = 'requests'
  soft_limit = 12   # past this, start another machine
  hard_limit = 24   # past this, shed load instead of queueing

auto_stop_machines = 'stop'
auto_start_machines = true
min_machines_running = 1

Khi tải tăng: khi số yêu cầu đang xử lý trên một máy vượt giới hạn mềm (soft limit), proxy sẽ bật một máy đang dừng và chuyển lưu lượng mới sang đó. Nhóm luồng WSGI cho mỗi máy 16 suất đồng thời thực sự, nên tôi đặt giới hạn mềm ở 12, tức khoảng 75% nhóm luồng, để máy số 2 khởi động khi các luồng vẫn còn dư sức, thay vì đợi đến lúc người dùng phải chờ tới vài giây. Giới hạn cứng (hard limit) đặt ở 24, gấp 1.5 lần nhóm luồng, đóng vai trò cầu dao: những đợt tăng vọt ngắn thì xếp hàng chờ luồng, còn vượt quá mức đó thì proxy sẽ từ chối bớt tải, thay vì để một máy bị quá tải tới mức sập. (Bản ASGI cũ chạy 8/20, tính theo ~3 suất thực của nó; chính việc nới rộng nhóm luồng mới cho phép nâng cả hai con số lên.)

Khi tải giảm: khi lưu lượng giảm, Fly tự động dừng các máy đang rảnh, xuống tới min_machines_running = 1. Máy đã dừng không tốn đồng tiền tính toán nào, chỉ tốn phần lưu trữ rootfs, nên chi phí nền của mỗi ứng dụng đúng nghĩa đen là một máy ảo nhỏ, mà lúc nào cũng có sẵn năng lực dự phòng cho những đợt tăng tải.

Ban đầu, ở đoạn này tôi có viết rằng một máy đã dừng “khởi động nguội (cold start) mất chưa tới một giây”. Câu đó sai, và cái sai ấy khá đắt. Đến khi chịu đo thực tế thay vì đoán, tôi mới thấy một lần khởi động nguội mất 25 đến 33 giây, và yêu cầu nào rơi vào một máy còn đang khởi động thì phải chờ trọn khoảng thời gian đó. Lúc đầu tôi đổ cho chính những lần khởi động nguội này tỉ lệ lỗi 22% trên bảng điều khiển của CDN, trong khi mọi lần kiểm tra tình trạng (health check) vẫn báo xanh. Hóa ra con số đó là các yêu cầu thăm dò Early Hints của chính CDN bị lỗi ở máy chủ gốc (origin); không có client thật nào nhận lỗi 504 cả. Dù vậy, chuyện khởi động nguội thì vẫn là thật.

Cách sửa không nằm ở mấy con số co giãn phía trên; chúng vẫn ổn. Vấn đề nằm ở những gì máy làm trong lúc khởi động, và ở việc yêu cầu Fly tạm ngưng (suspend) máy thay vì dừng hẳn (stop), để mỗi lần đánh thức máy chỉ còn là một lần khôi phục bộ nhớ mất khoảng 3 giây. Tôi đã viết riêng một bài về chuyện này: Thu về 0, và mỗi lần khởi động lại là một lần sập 30 giây, nói về cách tôi chẩn đoán và những gì cần thay đổi. Nếu bạn đang chạy bất cứ thứ gì trên Fly với auto_stop_machines, hãy đọc bài đó trước khi tin vào đoạn này.

Có một điểm tinh tế: kiểu đếm tải là requests, không phải connections. Máy khách hiện đại giữ kết nối duy trì (keep-alive) luôn mở, nên nếu đếm theo kết nối thì con số gần như đứng yên dù tải thực tế tăng, và bộ tự động co giãn sẽ không bao giờ được kích hoạt. Đếm số yêu cầu đang xử lý mới phản ánh đúng khối lượng công việc thực.

WebSocket co giãn theo một trục khác

#

Chợ mua bán tách máy chủ WebSocket ra thành một ứng dụng Fly thứ hai, dùng chung Docker image. Ứng dụng API chạy một worker × 16 luồng chặn dưới WSGI và đếm theo yêu cầu (giới hạn mềm 12). Ứng dụng WebSocket thì chạy 1 worker dưới ASGI với uvloop, trên một máy 512MB, và đếm theo kết nối:

[http_service.concurrency]
  type = 'connections'
  soft_limit = 1500
  hard_limit = 2000

Giữ một socket sống lâu gần như không tốn gì, nhưng nó chiếm một suất hàng giờ liền, trong khi một yêu cầu HTTP chỉ chiếm suất vài mili giây, nên không thể dùng chung một tín hiệu co giãn cho cả hai. Tách riêng ra thì mỗi nhóm máy co giãn theo đúng thước đo phản ánh tải thật của nó, và năng lực WebSocket lúc rảnh chỉ tốn 512MB chứ không phải 2GB. Về phía Channels, lớp Redis chạy với capacity: 1500, thông điệp hết hạn sau 60 giây, cộng thêm cơ chế duy trì kết nối cho socket mỗi 30 giây, vì proxy Redis của Fly sẽ tự đóng các socket BRPOP sống lâu mà Channels cần tới khi chúng không hoạt động.

Đẩy việc tính toán ra tầng biên và sang phía máy khách

#

Việc rẻ nhất cho máy chủ là việc máy chủ không bao giờ phải làm:

• Tệp tĩnh và tệp đa phương tiện (media) nằm trên dịch vụ lưu trữ đối tượng tương thích S3 của Fly, được phân phối qua CDN, với URL có chữ ký cho tệp đa phương tiện riêng tư. Không một byte ảnh nào phải đi qua các máy Django.
• Suy luận AI chạy trên điện thoại của người dùng. Cả hai ứng dụng đều nhúng một LLM nhỏ chạy cục bộ ngay trên thiết bị (mô hình 4B đã lượng tử hóa, khoảng 2.7GB). Phía máy chủ không tốn đồng nào cho suy luận, và tính năng này chạy được cả khi ngoại tuyến.
• Ứng dụng di động ưu tiên ngoại tuyến (offline-first) (SQLite trên thiết bị và một hàng đợi đồng bộ có cơ chế thử lại) giúp ứng dụng gom các thao tác ghi lại thành từng đợt và chịu được những vùng mất sóng, thay vì dội vào API hàng loạt yêu cầu lắt nhắt theo từng lần gõ phím.

Phần còn lại của bộ công nghệ, điểm nhanh

#

Xác thực dùng một dịch vụ định danh (identity provider) có sẵn cộng với khóa truy cập (passkey) WebAuthn, và kết nối WebSocket được xác thực trước khi nâng cấp giao thức. Postgres cho môi trường production, SQLite khi phát triển, cùng vài gói Django có sẵn cho trang quản trị và lịch sử kiểm toán (audit trail). Phía di động là React Native và TypeScript chạy trên Expo, với Expo Router và Tailwind, cập nhật OTA qua một máy chủ Expo Updates tự vận hành, còn gói thuê bao trong ứng dụng thì giao cho một dịch vụ quản lý thuê bao. Khâu kiểm soát chất lượng: pytest và mypy ở phía máy chủ, kiểm thử đơn vị và kiểm thử đầu-cuối (end-to-end) ở phía máy khách.

Những gì bạn nên “học lỏm”

#

Điều đáng mang về không nằm ở một thư viện cụ thể nào, mà ở cả vòng lặp. Tối ưu cho một máy rẻ tiền chạy thật nhanh (dùng Rust ở đường xử lý nóng, tái sử dụng kết nối, đặt bộ nhớ đệm chắn trước điểm nghẽn thật, đẩy được gì sang CDN và máy khách thì đẩy). Kiểm thử tải cho đến khi tìm ra chính xác mức yêu cầu đồng thời mà máy gãy. Đặt giới hạn mềm của bộ tự động co giãn ngay tại điểm gãy đó, để các máy rảnh tự dừng, và giữ tối thiểu một máy luôn chạy. Hai ứng dụng đang chạy production, có tính năng thời gian thực, có trợ lý AI, mà hóa đơn hằng tháng lúc bình thường chỉ là vài máy ảo rẻ nhất trên nền tảng.

Mấy tuần vừa rồi tôi dồn sức cho hai dự án có liên quan đến nhau. Dự án đầu tiên là tái hiện lại một bài báo năm 2024 đăng trên Scientific Reports của Lee và cộng sự, tựa đề “Social signals predict contemporary art prices better than visual features, particularly in emerging markets” (tạm dịch: tín hiệu xã hội dự đoán giá nghệ thuật đương đại tốt hơn đặc điểm thị giác, nhất là ở các thị trường mới nổi). Nhóm tác giả huấn luyện một mô hình XGBoost trên 34,200 bản ghi đấu giá của 590 nghệ sĩ còn sống. Dự án thứ hai là một nền tảng nghệ thuật có đồ thị tri thức (knowledge graph) nối nghệ sĩ, chủ sở hữu và các bản ghi đấu giá với nhau. Nói nôm na, nếu muốn đem một mô hình như của bài báo ra làm việc gì có ích thì bạn sẽ cần đến phần hạ tầng dữ liệu bao quanh nó, và nền tảng này chính là phần đó.

Làm cả hai, tôi cứ bị kéo về cùng một câu hỏi: liệu có đoán trước được một tác phẩm sẽ bán với giá bao nhiêu không? Câu trả lời là có, nhưng không phải nhờ nhìn vào tác phẩm. Những đặc trưng (feature) thực sự có tác dụng gần như đều mang tính xã hội.

Vì sao định giá nghệ thuật lại khó

#

Trước khi viết dòng mã nào, tôi bỏ vài ngày đọc xem giám định viên và nhà đấu giá định giá tác phẩm như thế nào. Danh sách yếu tố dài dằng dặc, mà phần lớn lại chẳng quy ra số liệu gọn gàng được. Đầu tiên là provenance, tức lịch sử nguồn gốc: ai từng sở hữu, từng trưng bày ở đâu, được nhắc tới trong những danh mục tác phẩm (catalogue) nào. Rồi đến chuyện xác nhận tác giả: một tác phẩm được quỹ của nghệ sĩ xác nhận có thể đắt gấp hàng chục, hàng trăm lần so với tác phẩm chỉ được ghi là “attributed to”, tức “được cho là của” người đó. Danh tiếng nghệ sĩ cũng quan trọng, và danh tiếng ấy được gây dựng từ các triển lãm cá nhân, những lần góp mặt ở biennale, tác phẩm được bảo tàng mua lại và cách giới phê bình đón nhận. Kế đến là tình trạng tác phẩm và lịch sử phục chế, độ hiếm của nó trong toàn bộ sự nghiệp nghệ sĩ, và chất liệu: sơn dầu trên toan thường bán được giá hơn tác phẩm trên giấy, còn tác phẩm trên giấy lại hơn tranh in. Tác phẩm từng nằm trong bộ sưu tập của một bảo tàng lớn thì như được đóng một con dấu mà thị trường thứ cấp tin tưởng. Thời điểm cũng có ảnh hưởng: dữ liệu so sánh từ năm năm trước là đã lỗi thời.

Chuyên gia của các nhà đấu giá còn hay nhắc tới “giá trị cảm xúc”: nhà sưu tập khao khát đến mức nào, các màn đua giá nóng lên ra sao, tác phẩm chạm tới cảm xúc riêng của từng người đến đâu. Chính yếu tố này có thể đẩy giá búa (hammer price) vượt xa mọi mức ước tính hợp lý. Bạn không mô hình hóa trực tiếp được thứ đó, nhưng vẫn nắm được đại khái hình dạng của nó một cách gián tiếp, thông qua mức ước tính của nhà đấu giá.

Trong thực tế, cách định giá phổ biến nhất là so sánh với các giao dịch tương đương (comparable sales): tìm kết quả đấu giá gần đây của những tác phẩm tương tự của cùng nghệ sĩ, rồi điều chỉnh theo những điểm khác nhau. Mô hình XGBoost cũng làm đúng việc ấy, chỉ khác là ở quy mô lớn hơn và với nhiều đặc trưng hơn hẳn số yếu tố mà một giám định viên có thể tự theo dõi bằng tay.

Luận điểm chính của bài báo

#

Lee và cộng sự đưa ra một lập luận khá ngược đời: nội dung thị giác của tác phẩm chỉ giải thích được rất ít về giá của nó. Mô hình chỉ dùng đặc trưng thị giác của họ, gồm màu sắc, bố cục, mật độ cạnh và vector nhúng (embedding) từ ResNet18, đạt R² khoảng 0.055. Tức là chỉ nhỉnh hơn một chút so với việc lấy giá trung bình ra đoán bừa.

Trong khi đó, một mô hình chỉ dùng các đặc trưng “xã hội” ở cấp nghệ sĩ (giai đoạn sự nghiệp, lịch sử triển lãm, giá đấu giá trước đây, thứ hạng trên ArtFacts) lại đạt R² ≈ 0.73. Thêm mức ước tính trước phiên của nhà đấu giá vào làm đặc trưng thì con số này leo lên 0.92.

Nói cách khác, bản thân tác phẩm gần như không quan trọng. Điều quan trọng là ai làm ra nó, và thị trường đã đánh giá người đó thế nào.

Luận điểm phụ của bài báo là khoảng cách này còn lớn hơn nữa ở các thị trường mới nổi, tức là mọi nơi nằm ngoài nhóm thị trường lâu đời gồm Mỹ, Anh, Pháp và Đức. Ở những thị trường đó, tín hiệu xã hội càng có trọng lượng, còn ước tính của chuyên gia lại kém chính xác hơn, nên dự đoán bằng thuật toán có nhiều đất dụng võ hơn.

Tái hiện bài báo

#

Yêu cầu đặt ra khá rõ ràng: tái hiện bài báo dưới dạng một MVP do một lập trình viên làm. Không triển khai lên môi trường production, không có luồng xử lý dữ liệu (pipeline) chạy theo thời gian thực. Chỉ cần làm lại cho sát với bài gốc, mã ở mức bản mẫu (prototype), kèm một bản báo cáo ghi lại những gì tìm được.

Dữ liệu

#

Nhóm tác giả đã đính kèm sẵn các tệp CSV đã làm sạch trong phần tài liệu bổ sung:

Tổng cộng khoảng 5 GB, nạp vào RAM thoải mái. Huấn luyện XGBoost trên tập dữ liệu cỡ này chưa tới năm phút bằng CPU của laptop, và mô hình chính cũng không cần GPU. Với dữ liệu dạng bảng ở quy mô này, huấn luyện cây tăng cường gradient (gradient-boosted tree) gần như chẳng tốn gì. Chuyện này rất dễ quên nếu mấy năm qua bạn chỉ quanh quẩn với mạng nơ-ron (neural network).

Đặc trưng

#

Mô hình dùng 38 đặc trưng, chia làm ba nhóm.

Về nghệ sĩ (30 đặc trưng):

• Nhân khẩu học: tuổi, giới tính, trình độ học vấn, có học trường top hay không.
• Sự nghiệp: thứ hạng ArtFacts, số triển lãm cá nhân, số triển lãm nhóm, số lần góp mặt ở biennale, giải thưởng.
• Bộ sưu tập: số bộ sưu tập tư nhân và công cộng đang giữ tác phẩm.
• Lịch sử giá: giá trung bình, trung vị, cao nhất và thấp nhất trong 5 và 10 lần bán gần nhất của nghệ sĩ.
• Lịch sử giá đã quy đổi theo kích thước (giá trên mỗi inch vuông).
• Địa lý: nơi nghệ sĩ làm việc và sinh sống, mã hóa thành các cờ theo quốc gia.
• Cờ khớp: thể loại của tác phẩm có đúng với thể loại quen thuộc của nghệ sĩ không? Quốc gia nơi diễn ra phiên bán có khớp không?

Về thị trường (8 đặc trưng):

• Hạng của nhà đấu giá (1–4).
• Mặt bằng giá theo quốc gia và khu vực trong năm đó (thấp nhất, trung bình, trung vị, cao nhất).

Về bản thân tác phẩm (không liên quan đến hình ảnh):

• Chiều rộng, chiều cao, diện tích tính bằng inch vuông.
• Nhóm chất liệu (tranh vẽ, tranh in, ảnh, điêu khắc, khác).

Để ý thứ bị thiếu: không có bất cứ thông tin nào về nội dung hình ảnh thật sự của tác phẩm. Phần đó chỉ xuất hiện trong một thí nghiệm cắt bỏ (ablation) riêng.

Chia tập huấn luyện và tập kiểm thử

#

Dữ liệu được chia theo thời gian chứ không chia ngẫu nhiên. Mọi giao dịch trước tháng 5 năm 2011 vào tập huấn luyện (~80%, ~27,360 bản ghi), mọi giao dịch sau đó vào tập kiểm thử (~20%, ~6,840 bản ghi). Nếu chia ngẫu nhiên, thông tin từ tương lai sẽ rò rỉ vào qua các đặc trưng lịch sử giá của nghệ sĩ. Khi các bản ghi của cùng một nghệ sĩ bị rải lẫn vào cả hai tập, những dòng kiểm thử đã “nhìn thấy” giá của nhau qua các cửa sổ trượt (rolling window), và R² của bạn sẽ đẹp hơn thực tế.

Kiểu lỗi này nhìn ra rồi thì thấy hiển nhiên, nhưng lần đầu làm thì rất dễ bỏ sót.

Mô hình

#

Tôi dùng mô hình hồi quy XGBoost (XGBoost regressor) để dự đoán log10(price_usd), dò siêu tham số (hyperparameter) max_depth và learning_rate, rồi đánh giá trên một tập kiểm định (validation set) để riêng. Có hai biến thể:

1. Không dùng ước tính của chuyên gia. Mục tiêu R² ≈ 0.73.
2. Có dùng ước tính của chuyên gia. Mục tiêu R² ≈ 0.92.

Biến thể “có ước tính” lấy thêm mức ước tính thấp và cao trước phiên của nhà đấu giá làm đặc trưng. Chỉ riêng hai con số ước tính này đã đạt R² ≈ 0.90. Cộng thêm các đặc trưng xã hội vào thì được thêm 0.02 nữa. Con số tuyệt đối thì nhỏ, nhưng 0.02 đó chính là phần mô hình thực sự dự đoán được vượt ra ngoài những gì chuyên gia đã biết.

Mục tiêu của tôi

#

Tôi không định vượt mặt bài báo. Mục tiêu chỉ là đạt R² trong khoảng ±0.03 so với kết quả của họ ở mọi điều kiện. Với các con số chính, ~0.73 khi chỉ dùng siêu dữ liệu (metadata) và ~0.92 khi có ước tính, việc tái hiện khá thuận lợi: XGBoost cho kết quả tất định khi cố định seed ngẫu nhiên, còn các đặc trưng được mô tả rõ ràng. Tôi đoán trước sẽ bị lệch ở hai chỗ. Một là thí nghiệm cắt bỏ với đặc trưng thị giác, nơi chỉ cần khác một chút về số chiều PCA hay khâu tiền xử lý ảnh là kết quả đã xê dịch. Hai là phần thị trường mới nổi, vốn chỉ có 4,346 bản ghi nên mức nhiễu nền cao hơn.

Vì sao đặc trưng thị giác gần như vô dụng

#

Với tôi, đây là kết quả thú vị nhất. Luồng xử lý ảnh của bài báo trích ra 8,971 con số cho mỗi bức ảnh:

• GIST descriptor (960 chiều): bố cục không gian tổng thể.
• Histogram of Oriented Gradients (2,915 chiều): cấu trúc các đường cạnh.
• Color histogram (4,096 chiều): phân bố bảng màu.
• ResNet18 features (1,000 chiều): vector nhúng cấp cao từ một mô hình đã huấn luyện sẵn (pretrained).
• Colorfulness (1 chiều): một con số đo độ rực màu.
• Complexity (1 chiều): một con số đo mật độ cạnh.

Nén hết chỗ đó bằng PCA rồi đưa vào XGBoost, bạn được R² ≈ 0.055. Riêng màu sắc đạt 0.056. Cấu trúc cạnh đạt 0.029. Còn vector nhúng của mạng nơ-ron chỉ được 0.009, coi như bằng không.

Cách giải thích gọn nhất là giá đấu giá được quyết định ở cấp nghệ sĩ chứ không phải ở từng tác phẩm. Hai bức tranh của cùng một nghệ sĩ sẽ bán được số tiền na ná nhau, bất kể trên toan vẽ gì, vì thứ người mua thật sự trả tiền là chữ ký.

Ai từng đọc phần ghi chú trong danh mục đấu giá sẽ hiểu vì sao lại như vậy. Gần như toàn bộ câu chữ dành cho lịch sử nguồn gốc, lịch sử triển lãm và các giao dịch tương đương. Bản thân tác phẩm thì hầu như chẳng được mô tả gì.

Nếu nghiêm túc nhìn vào con số 5% đó, thì nội dung thẩm mỹ của một tác phẩm gần như chẳng dính dáng gì tới giá trị thị trường của nó. Thị trường trả tiền cho thứ gì thì trả, nhưng không phải cho những gì nằm trên toan. Một mô hình hiểu nghệ thuật đến từng pixel sẽ đoán giá kém hơn một mô hình chỉ biết mỗi CV của nghệ sĩ.

Giai đoạn 3 chỉ làm khi đủ điều kiện

#

Cột đường dẫn ảnh trong dữ liệu của bài báo trỏ tới các URL còn hoạt động vào năm 2012. Đến năm 2026 thì phần lớn đã chết. Trong kế hoạch, tôi đã ghi chú rủi ro này ngay từ ngày thứ 8: lấy ngẫu nhiên một trăm URL xem còn bao nhiêu cái mở được. Nếu hơn một nửa đã mất thì bỏ qua hẳn giai đoạn thị giác và ghi lại lý do.

Dù sao thì đặc trưng thị giác cũng chỉ giải thích khoảng 5% độ biến thiên của giá. Mất hai tuần vật lộn với đống đường dẫn hỏng chỉ để xác nhận một con số nhỏ cỡ đó thì không đáng. Tốt hơn là ghi chuyện đường dẫn chết vào báo cáo rồi làm tiếp phần khác.

Thị trường lâu đời và thị trường mới nổi

#

Bài báo huấn luyện các mô hình riêng cho thị trường lâu đời (Mỹ, Anh, Pháp, Đức) và thị trường mới nổi (19 quốc gia còn lại). Kết quả chính như sau:

Có hai điểm đáng chú ý. Thứ nhất, tín hiệu xã hội ở thị trường mới nổi lại quan trọng hơn chứ không kém đi. Tôi cứ tưởng thị trường lâu đời có dữ liệu phong phú hơn thì đặc trưng xã hội sẽ phát huy tốt hơn, nhưng hóa ra ngược lại.

Thứ hai, ước tính của chuyên gia ở thị trường mới nổi kém chính xác hơn. Đó chính là khoảng cách giữa 0.916 và 0.859 sau khi thêm ước tính vào. Ở thị trường lâu đời, một dự đoán bằng thuật toán phải cạnh tranh với chuyên gia của một nhà đấu giá lớn, người có cả chục năm dữ liệu giao dịch tương đương chống lưng. Còn ở thị trường mới nổi, chuyên gia có ít dữ liệu hơn, nên thuật toán có nhiều chỗ để chứng tỏ giá trị hơn.

Nếu một ngày nào đó bạn muốn thương mại hóa một mô hình như thế này, thì thị trường mới nổi là nơi nó thật sự đáng đồng tiền bát gạo.

Những giới hạn cần nói rõ

#

Đây là bản tái hiện một bài báo, không phải hệ thống chạy trên môi trường production. Không có luồng xử lý dữ liệu thời gian thực: mô hình được huấn luyện trên dữ liệu đấu giá 1996–2012 và không bao giờ được cập nhật. Cũng không triển khai gì cả: đầu ra là notebook và một bản báo cáo, chứ không phải API dự đoán. Không có cơ chế phát hiện trôi dạt dữ liệu (data drift), nên huấn luyện xong thì mô hình hoàn toàn không biết thị trường đã thay đổi từ lúc nào. Tập dữ liệu cũng bị đóng băng, nên crypto art, NFT hay những biến động thị trường sau COVID đơn giản là không có trong đó. Nếu muốn dự đoán giá ở các nhà đấu giá Hàn Quốc, bạn sẽ cần đặc trưng riêng cho từng nhà đấu giá, và có khi cả một mô hình riêng cho thị trường Hàn Quốc. Ở đây chưa có gì chuyên biệt đến mức ấy.

Mô hình cũng chỉ phản ánh các quy luật trong quá khứ. Có ý kiến cho rằng thị trường đương đại đã thay đổi về cấu trúc vào khoảng năm 2015, khi các hội chợ nghệ thuật trở thành kênh bán hàng chính của thị trường sơ cấp và một thế hệ nhà sưu tập mới bước vào cuộc chơi. Nếu đúng vậy, các quy luật của giai đoạn 1996–2012 có thể không còn áp dụng được nữa.

Từ bài báo đến nền tảng

#

Đọc xong bài báo, tôi nhìn dự án thứ hai theo một cách khác hẳn. Ban đầu nền tảng này được định hình là một sàn gọi vốn cộng đồng (crowdfunding) cho các triển lãm nghệ thuật. Nghệ sĩ gọi vốn cho các triển lãm sắp tới, còn nhà đầu tư được tiếp cận nghệ sĩ mới nổi sớm hơn so với khi chờ họ lên sàn đấu giá.

Phần sản phẩm người dùng nhìn thấy được cố tình giữ đơn giản. Nghệ sĩ đăng các triển lãm sắp tới đang cần vốn (địa điểm, ngày tổ chức, các tác phẩm dự kiến). Nhà đầu tư rót tiền cho từng triển lãm cụ thể theo các mức ($100, $500, $1k, $5k), và được chia phần lời khi tác phẩm bán được. Tác tử AI (AI agent) lo phần lớn việc trò chuyện giữa nghệ sĩ và nhà đầu tư, nên hai bên không cần cùng trực tuyến mà câu chuyện vẫn tiếp tục. Điều này đặc biệt có ích khi một phòng tranh (gallery) ở Hàn Quốc làm việc với một nhà sưu tập ở Mỹ, hai bên lệch nhau tới 14 tiếng.

Một khi đã thấm rằng tài sản thật sự là người nghệ sĩ chứ không phải tác phẩm, thì mô hình dữ liệu (data model) cũng phải đổi theo. Thứ bạn cần ghi lại là ai từng sở hữu từng tác phẩm, tác phẩm đã được trưng bày ở đâu, các tác phẩm tương đương bán được bao nhiêu, và còn ai khác đang giữ tác phẩm của cùng nghệ sĩ. Chuỗi sở hữu, sự công nhận từ các tổ chức, dữ liệu đấu giá để so sánh, mạng lưới nhà sưu tập: đồ thị tri thức sinh ra chính là để lưu những thứ như vậy.

Mô hình dữ liệu được tôi cố tình giữ nhỏ gọn: nghệ sĩ, tác phẩm, các lần bán đấu giá, các giai đoạn sở hữu, và một nhật ký ghi lại nguồn gốc của chính dữ liệu, để bản ghi nào cũng truy ngược được về nơi nó được thu thập (scrape). Phần cuối nghe như việc sổ sách, nhưng khi dữ liệu là đi thu thập về thì phải có nó mới tin được đồ thị.

Ứng dụng di động hiển thị toàn bộ dữ liệu này thành một đồ thị bố trí theo lực (force-directed). Có một thanh trượt thời gian để bạn kéo qua từng năm và xem mạng lưới thay đổi ra sao: nhà sưu tập nào tham gia vào lúc nào, nghệ sĩ nào được bảo tàng nào để mắt tới, tác phẩm nào đổi chủ trong đợt suy thoái năm 2008.

Mỗi loại thực thể có hình dạng và màu sắc riêng. Nghệ sĩ là hình thoi, tác phẩm là hình chữ nhật bo góc, nhà đấu giá là hình lục giác, còn các bên sở hữu như nhà sưu tập, người buôn tranh, bảo tàng hay di sản nghệ sĩ (estate) là những hình tròn khác màu.

Mấy hình dạng này không phải để trang trí. Khi thu nhỏ để xem vài trăm nút cùng lúc, chỉ cần nhìn đường viền là biết đó là loại thực thể nào, khỏi phải chờ nhãn hiện lên. Một hình thoi có nhiều hình tròn vây quanh là một nghệ sĩ cùng mạng lưới nhà sưu tập của họ. Một hình lục giác nối với nhiều hình thoi là một nhà đấu giá đang phụ trách cả một danh sách nghệ sĩ. Chỉ cần liếc qua là đọc được cấu trúc của cả một thị trường.

Thẻ (tab) thứ hai hiển thị cùng dữ liệu đó trên một trục thời gian: các giai đoạn sở hữu là những thanh ngang, còn mỗi lần bán là một điểm sự kiện. Vẫn là đồ thị ấy, chỉ nhìn qua một lăng kính khác. Cách này hữu ích khi bạn muốn xem ai nắm giữ tác phẩm nào theo trình tự thời gian, thay vì hình dạng của mạng lưới ở một thời điểm.

Bản thân nền tảng này không phải công cụ dự đoán giá. Nó là tầng dữ liệu nằm bên dưới một công cụ như thế. Nếu muốn nuôi một mô hình kiểu của Lee và cộng sự bằng dữ liệu thời gian thực, luôn được cập nhật, thay vì mấy tệp CSV đóng băng từ năm 2012, thì đây chính là cấu trúc bạn cần.

Định giá bằng đám đông, dưới dạng một trò chơi

#

Phần tôi chưa làm, nhưng lại là phần tôi hứng thú nhất, là biến việc định giá nghệ thuật thành một trò chơi.

Bài báo của Lee và cộng sự lấy mức ước tính trước phiên của nhà đấu giá làm đặc trưng, và nhờ nó mà R² tăng vọt. Những ước tính này có giá trị vì chúng là phán đoán tổng hợp của các chuyên gia được đào tạo bài bản, đã từng xem hàng nghìn tác phẩm tương đương, và bản thân họ cũng có quyền lợi gắn với kết quả. Nhưng chuyên gia của nhà đấu giá là nguồn lực vừa hiếm vừa đắt. Cả thế giới chỉ có vài trăm người, họ chỉ làm việc với những lô tác phẩm được ký gửi cụ thể, và họ không đụng tới phần đuôi dài (long tail): những nghệ sĩ mà chưa ai mang tác phẩm đi ký gửi.

Tôi cứ quay đi quay lại một câu hỏi: liệu có tổng hợp được một tín hiệu tương đương từ phán đoán của một nhóm người đông hơn và rẻ hơn nhiều hay không?

Thiết kế sơ bộ như sau:

• Cho người dùng xem một tác phẩm: ảnh, kích thước, năm sáng tác, tên nghệ sĩ, CV tóm tắt.
• Hỏi họ tác phẩm đó sẽ bán được bao nhiêu ở phiên đấu giá.
• Cho họ chọn một khoảng giá, hoặc đoán thẳng con số giá búa.
• Sau khi họ chốt câu trả lời thì mới cho xem giá bán thật.
• Chấm độ chính xác của họ bằng điểm Brier (Brier score), tích lũy theo thời gian.
• Hiển thị bảng xếp hạng, chuỗi ngày chơi liên tục (streak) và huy hiệu cho những chuỗi đoán trúng liên tiếp.
• Đánh trọng số cho các dự đoán sau này của từng người dựa trên độ chính xác trước đó của họ.

Về bản chất, đây là một thị trường dự đoán (prediction market) cho giá tranh, chỉ khoác lên lớp áo của một trò đoán giá. Vòng lặp y hệt các trò đoán địa điểm trên bản đồ hay điểm giải cờ thế (puzzle) trên các trang cờ vua trực tuyến: chơi lại được nhiều lần, chấm điểm được, và có phản hồi để bạn luyện kỹ năng dần lên. Ai đoán giỏi sẽ leo lên bảng xếp hạng, và những lần đoán sau của họ sẽ có trọng lượng lớn hơn trong tín hiệu tổng hợp.

Cái hay nằm ở phía mô hình. Kết quả tổng hợp có trọng số của các lượt đoán trở thành một đặc trưng để đưa vào XGBoost, bên cạnh các tín hiệu xã hội. Nếu trung vị các lượt đoán của đám đông, sau khi đánh trọng số theo độ chính xác, bám sát giá búa, thì bạn đã có trong tay thứ gần giống một bản ước tính “nhân tạo” của nhà đấu giá cho những tác phẩm chưa có ước tính thật. Đó đúng là lỗ hổng ở phần đuôi dài các nghệ sĩ, chỗ mà mô hình của Lee và cộng sự cần được hỗ trợ nhất.

Còn một khía cạnh nữa là bài toán khởi động nguội (cold start). Mô hình học tốt với những nghệ sĩ có lịch sử giá dày dặn, nhưng học rất tệ với nghệ sĩ mới chỉ có ba lần bán. Ba lần bán cộng thêm một nghìn lượt đoán của đám đông thì ít ra cũng có cái để làm việc. Định giá bằng đám đông là một cách tạo ra tín hiệu huấn luyện cho những trường hợp mà dữ liệu gốc không bao phủ tới.

Trò chơi hóa (gamification) quan trọng ở đây, vì cách duy nhất để đám đông trở nên đáng tin là làm cho việc tham gia đủ vui để người ta chơi thật nhiều. Một biểu mẫu hỏi đúng một câu chỉ cho bạn dữ liệu nhiễu, từ những người bấm cho xong một lần rồi thôi. Còn một chuỗi ngày chơi liên tục, có bảng xếp hạng và huy hiệu cho người đoán sát thì giữ chân được cùng một người, để họ đưa ra 500 dự đoán cân nhắc kỹ lưỡng trong một năm. Số lượng lớn, cộng với việc người chơi tự sàng lọc (người đoán giỏi ở lại, người đoán dở chán rồi bỏ đi), mới là thứ cho bạn tín hiệu thay vì nhiễu.

Trước khi xây bất cứ thứ gì, tôi còn phải trả lời vài câu hỏi thiết kế. Nên cho người dùng xem bao nhiêu thông tin: chỉ ảnh và CV, hay cả các giao dịch tương đương? Càng nhiều ngữ cảnh thì đoán càng có cơ sở, nhưng quá một ngưỡng nào đó thì người dùng chủ yếu chỉ nhắc lại những gì bạn vừa cho họ xem. Phản hồi về giá nên chi tiết đến đâu: tiết lộ chính xác giá búa, chỉ đưa một khoảng, hay chỉ báo họ có nằm trong ±20% hay không? Chi tiết quá thì người chơi quen neo vào những con số cụ thể, còn mơ hồ quá thì họ không tự điều chỉnh được. Rồi còn chuyện lách bảng xếp hạng: người chơi sẽ tìm đến những nghệ sĩ họ đã biết, mà đoán giá một bức Banksy thì chủ yếu là kiến thức đố vui chứ đâu phải kỹ năng. Có lẽ cách xử lý là bắt buộc chọn tác phẩm ngẫu nhiên, giống cách các ứng dụng học ngoại ngữ chọn bài học, cộng thêm một bảng xếp hạng riêng cho các vòng “chơi mù” giấu tên nghệ sĩ. Cuối cùng, thiên kiến nhận thức muộn (hindsight bias) là không tránh được: một khi người dùng đã biết một bức Basquiat bán được $110M, họ không thể giả vờ là chưa biết. Thứ giữ cho vòng lặp này trung thực là nguồn tác phẩm mới, chưa ai xem, mà nguồn đó thì mỗi tuần chỉ có hạn.

Cách tiếp cận trò chơi hóa cũng giúp gắn kết hai nửa của nền tảng. Phía gọi vốn cộng đồng thưởng cho nhà đầu tư khi triển lãm làm ăn có lãi. Phía trò đoán giá thì thưởng cho bất kỳ ai đoán giá giỏi, dù có bỏ tiền đầu tư hay không. Cả hai đều xuất phát từ cùng một ý tưởng: biến phán đoán tập thể của đám đông thành một tín hiệu có thể giao dịch. Một bên giao dịch bằng vốn, bên kia giao dịch bằng sự chú ý. Người chơi nào thật sự có nghề thì về sau có thể “lên lớp” sang phía nhà đầu tư, mang theo một thành tích đoán giá kiểm chứng được. Đó là một bộ lọc tốt hơn nhiều so với kiểu “quen đúng ông chủ phòng tranh”.

Những gì tôi rút ra

#

Ước tính trước phiên thật sự rất tốt. Nhà đấu giá hay bị chê là định giá thiếu minh bạch, nhưng chỉ riêng các ước tính của họ đã giải thích được gần 90% độ biến thiên của giá. Chuyên gia làm cách nào thì làm, họ làm tốt. Vậy mà xét về mặt thống kê, bản thân tác phẩm lại gần như không quan trọng, một sự thật khá khó chịu nếu bạn yêu nghệ thuật vì cái đẹp. Thị trường không định giá thứ bạn nhìn thấy. Nó định giá dựa trên số tiền người khác đã trả cho những tác phẩm na ná.

Về phía mô hình hóa, có hai thói quen tỏ ra rất đáng giá. Chia dữ liệu theo thời gian là cách trung thực duy nhất để đánh giá mô hình dự đoán giá. Chia ngẫu nhiên thì cho bạn những con số R² đẹp như mơ, nhưng đưa vào môi trường production là vỡ. Và cây tăng cường gradient vẫn là công cụ phù hợp cho bài toán này: XGBoost đánh bại mọi mô hình cơ sở (baseline) dùng mạng nơ-ron trong bài báo, và với dữ liệu dạng bảng ở quy mô này, lại có sẵn chừng ấy đặc trưng được thiết kế công phu, thì chẳng có lý do gì phải tìm đến transformer.

Về mặt kinh doanh, cơ hội thú vị nằm ở các thị trường mới nổi, nơi định giá của chuyên gia còn mỏng nhất và dự đoán bằng thuật toán có nhiều khoảng trống nhất để lấp. Đám đông cũng là một nguồn dữ liệu đang bị bỏ phí. Đặc trưng mạnh nhất trong mô hình của Lee và cộng sự là mức ước tính trước phiên của nhà đấu giá. Nếu một đám đông đã được hiệu chỉnh tạo ra được tín hiệu tương đương cho phần đuôi dài các nghệ sĩ, thì đó là một cơ hội thật, vừa làm đầu vào cho mô hình, vừa có thể đứng riêng thành một sản phẩm.

Rốt cuộc, hai dự án bổ trợ cho nhau nhiều hơn tôi dự tính. Bản tái hiện bài báo cho tôi biết điều gì dự đoán được giá. Phần làm nền tảng cho tôi biết cần cấu trúc dữ liệu thế nào để đem hiểu biết đó ra dùng. Ý tưởng trò chơi hóa nối hai thứ lại: đồ thị tri thức cung cấp tác phẩm và lịch sử giao dịch, trò đoán giá tạo ra một đặc trưng ước tính từ đám đông, rồi mô hình dùng đặc trưng đó cùng các tín hiệu xã hội để dự đoán giá cho những nghệ sĩ mà nếu thiếu nó thì mô hình hoàn toàn không nhìn thấy.

Chưa phần nào xong cả. Bản tái hiện bài báo mới là một bản mẫu chạy được kèm bản báo cáo, nền tảng là một bản chạy thử với dữ liệu mẫu, còn trò đoán giá thì mới chỉ nằm trên mấy ghi chú thiết kế bạn vừa đọc. Nhưng ý tưởng xuyên suốt đủ nhất quán để tôi tin rằng hướng đi đúng đã khá rõ: định giá nghệ sĩ thay vì tác phẩm, tổng hợp ý kiến đám đông thay vì chỉ trông vào chuyên gia, và coi giá trị của tác phẩm là thứ cả thị trường cùng tạo ra, chứ không phải thứ do chuyên gia định sẵn rồi ban xuống.

Nếu có thời gian để xây, đó sẽ là phiên bản tôi làm tiếp theo.