Từ Autoresearch Đến Harness AI Phân Tích Chứng Khoán
Muốn hiểu một harness tốt theo cách khách quan, hãy bắt đầu từ một hệ thống đã công khai cách vận hành, có phạm vi đủ nhỏ để đọc hết và có tiêu chí đánh giá rõ ràng.
autoresearch của Andrej Karpathy là một ví dụ như vậy. Dự án giao cho AI Agent nhiệm vụ sửa chương trình huấn luyện mô hình, chạy thử trong quỹ thời gian cố định, đọc kết quả rồi quyết định giữ hay bỏ thay đổi. Toàn bộ vòng lặp được mô tả trong một repository nhỏ, thay vì chỉ xuất hiện trong một bài giới thiệu sản phẩm.1
Bài này không dùng autoresearch để chứng minh AI có thể tìm ra lợi thế đầu tư. Mục tiêu hẹp hơn: phân tích những quyết định thiết kế khiến Agent có thể thử nghiệm nhiều lần mà người dùng vẫn biết nó đã sửa gì, đo bằng gì và vì sao một kết quả được giữ lại.
Đọc nền: Harness Engineering là gì trong AI phân tích chứng khoán?
Autoresearch giải bài toán gì?
autoresearch đặt AI Agent vào một bài toán nghiên cứu mô hình ngôn ngữ có thể đo được:
- Agent sửa chương trình huấn luyện.
- Mỗi thử nghiệm chạy trong năm phút.
- Hệ thống đo
val_bpb— số bit kiểm định trên mỗi byte, càng thấp càng tốt. - Kết quả tốt hơn được giữ lại; kết quả kém hơn bị loại bỏ.
- Agent tiếp tục vòng thử nghiệm tiếp theo.
Điểm đáng học không phải việc Agent chạy qua đêm. Điểm đáng học là quyền tự do của Agent được đặt bên trong một cấu trúc rất chặt: chỉ một tệp được sửa, hàm đánh giá bị khóa, thời gian chạy cố định và mỗi thử nghiệm đều để lại dấu vết.2
Nếu chỉ đưa cho Agent yêu cầu “hãy làm mô hình tốt hơn”, nó có thể thay đổi cùng lúc dữ liệu, cách đánh giá, kiến trúc và thời gian huấn luyện. Một con số đẹp hơn khi đó chưa chắc đến từ mô hình tốt hơn. autoresearch tách những phần này ra để các lần chạy còn có thể so sánh.
Ba tệp tạo nên bộ khung tối thiểu
Repository có nhiều tệp hỗ trợ, nhưng ba tệp thể hiện rõ nhất thiết kế của harness.
| Tệp | Ai kiểm soát? | Vai trò |
|---|---|---|
program.md | Người dùng viết, Agent đọc | Ghi mục tiêu, phạm vi, quy tắc chạy và cách quyết định giữ hay bỏ thử nghiệm |
train.py | Agent được phép sửa | Chứa mô hình, bộ tối ưu và vòng huấn luyện cần cải tiến |
prepare.py | Bị khóa trong quá trình thử nghiệm | Giữ dữ liệu chuẩn bị, giới hạn thời gian và hàm đánh giá |
Cách chia này tạo ra ba lớp trách nhiệm khác nhau:
- ý định nằm trong
program.md; - phần cần khám phá nằm trong
train.py; - thước đo và ranh giới nằm trong
prepare.py.
Nếu Agent được sửa cả thước đo, nó có thể làm con số đẹp hơn mà không làm bài toán tốt hơn. Nếu người dùng nhét mọi thứ vào một prompt, các quy tắc quan trọng dễ trôi khỏi ngữ cảnh sau nhiều vòng. Việc tách tệp vì thế không chỉ để repository gọn hơn; nó làm rõ phần nào được thay đổi và phần nào phải ổn định.
Vòng lặp thử nghiệm được thiết lập như thế nào?
Hướng dẫn trong program.md mô tả một vòng lặp có thể kiểm tra lại:
Đọc trạng thái Git
→ chọn một ý tưởng thử nghiệm
→ sửa train.py
→ tạo commit
→ chạy trong ngân sách cố định
→ đọc metric và mức dùng bộ nhớ
→ ghi results.tsv
→ giữ, bỏ hoặc đánh dấu lỗi
→ lặp lạiMỗi dòng trong results.tsv ghi commit, metric, bộ nhớ, trạng thái và mô tả ngắn. Git giữ phiên bản chương trình; tệp kết quả giữ lịch sử thử nghiệm. Hai loại bằng chứng này trả lời hai câu hỏi khác nhau:
- chương trình đã thay đổi ở đâu;
- thay đổi đó tạo ra kết quả gì.
Một lần chạy bị lỗi cũng được ghi lại thay vì biến mất. Điều này quan trọng vì nếu chỉ lưu các thử nghiệm thành công, người đọc không biết Agent đã thử bao nhiêu phương án trước khi tìm thấy kết quả tốt hơn.
Sáu quyết định khiến đây trở thành một harness
Một mục tiêu đo được
Agent không được yêu cầu chung chung là “nghiên cứu tốt hơn”. Nó tối ưu một metric đã xác định trước. Metric không thay thế đánh giá của con người, nhưng giúp vòng lặp biết khi nào một thay đổi đáng xem xét.
Một phần được phép thay đổi
Agent chỉ sửa train.py. Phạm vi nhỏ làm diff dễ đọc và giảm khả năng một thử nghiệm vô tình thay đổi cả dữ liệu lẫn cách chấm điểm.
Một bộ đánh giá bị khóa
Hàm đánh giá và dữ liệu chuẩn bị nằm ngoài phạm vi chỉnh sửa. Đây là chốt chống việc Agent “tối ưu bài thi” bằng cách sửa chính bài thi.
Một ngân sách cố định
Mỗi lần huấn luyện có cùng giới hạn thời gian. Nhờ đó, Agent không thể đạt metric tốt hơn chỉ bằng cách chạy lâu hơn. Đổi lại, kết quả chỉ so sánh hợp lý trên cùng môi trường tính toán; chính README của dự án cũng nêu giới hạn này.1
Một nhật ký cho cả thất bại
keep, discard và crash đều là trạng thái hợp lệ. Harness không giả vờ mọi vòng lặp đều tạo ra tiến bộ.
Một vai trò rõ cho con người
Người dùng đặt mục tiêu, viết hướng dẫn và quyết định cấu trúc đánh giá. Agent đề xuất thay đổi và thực hiện vòng thử nghiệm. Quyền tự chủ nằm trong ranh giới đã được con người thiết kế.
Đối chiếu với một harness ở quy mô lớn hơn
OpenAI mô tả một thử nghiệm nội bộ nơi Codex tạo mã, kiểm thử, tài liệu và công cụ vận hành cho một sản phẩm. Các con số về quy mô và tốc độ trong case này là số liệu OpenAI tự báo cáo, nên không nên xem như benchmark độc lập.3
Điều hữu ích hơn là những điểm cấu trúc trùng với autoresearch:
- repository là nguồn sự thật mà Agent có thể đọc;
- nhiệm vụ lớn được chia thành phần nhỏ có điều kiện hoàn thành;
- log, metric và giao diện kiểm thử được làm cho Agent quan sát được;
- quy tắc quan trọng được chuyển thành linter hoặc kiểm thử thay vì chỉ viết trong prompt;
- con người ưu tiên công việc, đặt tiêu chí và xử lý những chỗ cần phán đoán.
autoresearch dùng một tệp được sửa và một metric. Case OpenAI dùng repository lớn, CI, quan sát hệ thống và kiểm tra kiến trúc. Quy mô khác nhau, nhưng nguyên tắc chung không đổi: Agent chỉ làm việc ổn định khi mục tiêu, quyền, phản hồi và bằng chứng đều hiện diện trong môi trường của nó.
Điểm phải dừng trước khi chuyển sang chứng khoán
Không thể lấy nguyên vòng lặp “metric tốt hơn thì giữ” của autoresearch rồi áp thẳng vào chiến lược đầu tư.
Trong huấn luyện mô hình của ví dụ này, các thử nghiệm dùng cùng dữ liệu chuẩn bị, cùng ngân sách thời gian và cùng hàm đánh giá. Trong nghiên cứu thị trường, dữ liệu thay đổi theo thời gian, chế độ thị trường không ổn định và số lần thử tham số làm tăng nguy cơ chọn nhầm một kết quả đẹp do ngẫu nhiên.
Nghiên cứu về backtest overfitting chỉ ra rằng khi thử nhiều cấu hình trên cùng dữ liệu lịch sử rồi chọn cấu hình tốt nhất, xác suất chọn phải một kết quả không bền vững sẽ tăng lên.4 Vì vậy, một harness tài chính không nên chỉ lưu “phương án thắng”. Nó còn phải lưu:
- tổng số giả thuyết và cấu hình đã thử;
- mốc thời gian mà mỗi thử nghiệm được phép sử dụng;
- cách tách dữ liệu trong mẫu và ngoài mẫu;
- chi phí, thanh khoản và giả định thực thi;
- kết quả thất bại hoặc không có ý nghĩa;
- lý do kinh tế đứng sau giả thuyết.
Đây là khác biệt quan trọng nhất giữa học cấu trúc của autoresearch và sao chép nó.
Chuyển từng nguyên tắc sang nghiên cứu tài chính
Trong autoresearch | Khi chuyển sang nghiên cứu tài chính |
|---|---|
program.md ghi luật thử nghiệm | Bản mô tả câu hỏi, phạm vi dữ liệu, giả định và điều kiện dừng |
Agent sửa train.py | Agent sửa chương trình biến đổi dữ liệu hoặc kiểm tra một giả thuyết |
prepare.py giữ phần đánh giá cố định | Pipeline dữ liệu và quy tắc đánh giá được khóa theo từng đợt nghiên cứu |
| Thời gian chạy năm phút | Ngân sách tính toán, khoảng dữ liệu và ngày chốt thông tin được xác định trước |
val_bpb là metric chính | Một tập tiêu chí gồm chất lượng dữ liệu, độ ổn định, rủi ro và kiểm định ngoài mẫu |
results.tsv lưu mọi lần chạy | Sổ thử nghiệm lưu cả kết quả đạt, không đạt và lỗi |
| Git giữ phiên bản code | Git hoặc cơ chế tương đương giữ code, cấu hình và thay đổi giả thuyết |
keep hoặc discard | “Đáng nghiên cứu tiếp” hoặc “chưa đủ bằng chứng”, không phải lệnh mua hay bán |
Bảng này cố ý không ánh xạ val_bpb sang lợi nhuận hay Sharpe ratio duy nhất. Một metric đơn có thể phù hợp với bài toán huấn luyện bị ràng buộc chặt; nghiên cứu tài chính cần nhiều lớp kiểm tra hơn và vẫn phải dành chỗ cho phán đoán của người dùng.
Một cấu trúc thư mục trung lập để thử nghiệm
Trước khi chọn thư viện dữ liệu, có thể bắt đầu bằng cấu trúc không gắn với công cụ cụ thể:
nghien-cuu/
├── research.md # Câu hỏi, giả thuyết và giới hạn
├── protocol.yaml # Dữ liệu, mốc thời gian, metric và điều kiện dừng
├── experiment.py # Phần Agent được phép sửa
├── evaluation.py # Phép kiểm bị khóa trong một đợt nghiên cứu
├── results.tsv # Toàn bộ thử nghiệm, kể cả lỗi
├── data/ # Dữ liệu đầu vào theo điều kiện của nguồn
└── reports/ # Bảng, biểu đồ và nhận xétCấu trúc này chưa phải chuẩn chung. Nó chỉ dịch ba vai trò của autoresearch sang một bài toán khác: hướng dẫn, phần được thay đổi và bộ đánh giá ổn định.
Một yêu cầu ban đầu cho Agent có thể viết như sau:
Hãy đọc
research.mdvàprotocol.yaml, sau đó kiểm tra xem dữ liệu và phép đánh giá đã đủ rõ chưa. Chỉ được sửaexperiment.py. Không sửaevaluation.pyhoặc ngày chốt dữ liệu. Sau mỗi lần chạy, ghi cấu hình, phiên bản code, metric, cảnh báo và trạng thái vàoresults.tsv. Nếu thiếu dữ liệu, phát hiện rò rỉ tương lai hoặc không xác định được đơn vị, dừng và báo lại thay vì tiếp tục tối ưu.
Prompt này chưa hứa tạo ra một chiến lược tốt. Nó chỉ tạo điều kiện để người dùng biết Agent đã làm gì và ngăn một số đường tắt dễ làm sai nghiên cứu.
Vnstock nằm ở đâu trong cấu trúc này?
Sau khi bộ khung đã rõ, Vnstock có thể là một trong các lớp công cụ Python mà Agent sử dụng để người dùng kết nối và chuẩn hoá dữ liệu từ nguồn bên thứ ba. Bài về cách Vnstock làm việc với AI Agent giải thích vai trò này chi tiết hơn.
Vnstock không phải bằng chứng rằng harness tạo ra lợi thế đầu tư. Thư viện cũng không thay thế:
- thiết kế giả thuyết;
- cách chia mẫu và kiểm soát rò rỉ dữ liệu;
- nhật ký toàn bộ thử nghiệm;
- tiêu chí đánh giá ngoài mẫu;
- quyết định của người chịu trách nhiệm nghiên cứu.
Nếu dùng Vnstock, Agent Guide có thể giúp Agent tìm đúng tài liệu và giao diện lập trình hiện tại. Bài Chuẩn hoá dữ liệu chứng khoán khi Vibe Coding cung cấp thêm các lỗi định dạng cần đưa vào phép kiểm. Hai thành phần này hỗ trợ triển khai; chúng không tự chứng minh kết quả nghiên cứu.
Nên học gì từ autoresearch?
Bài học hữu ích nhất không phải “hãy để AI tự chạy qua đêm”. Đó là bốn câu hỏi phải trả lời trước khi tăng quyền tự chủ:
- Agent được thay đổi chính xác phần nào?
- Phần nào phải bị khóa để kết quả còn so sánh được?
- Mọi thử nghiệm sẽ để lại bằng chứng gì?
- Điều kiện nào buộc Agent dừng và chuyển lại cho con người?
Nếu chưa trả lời được bốn câu này, thêm nhiều Agent hoặc nhiều công cụ chỉ làm vòng lặp chạy nhanh hơn, không làm kết luận đáng tin hơn.
Câu hỏi thường gặp
Autoresearch có phải bằng chứng AI tự nghiên cứu tốt hơn con người không?
Không. Repository cho thấy một cách tổ chức thử nghiệm tự động trong phạm vi hẹp. Chất lượng giả thuyết, độ bền của cải tiến và khả năng chuyển sang bài toán khác vẫn cần được đánh giá riêng.
Có thể dùng nguyên metric lợi nhuận để quyết định giữ hay bỏ không?
Không nên. Tối ưu lặp trên lợi nhuận lịch sử rất dễ chọn phải cấu hình khớp nhiễu. Harness cần ghi số lần thử, tách ngoài mẫu, kiểm soát chi phí và dùng nhiều tiêu chí thay vì một con số duy nhất.
Harness có nhất thiết phải có nhiều Agent không?
Không. autoresearch cho thấy một Agent, một tệp hướng dẫn, một phần được sửa và một bộ đánh giá đã đủ tạo thành vòng lặp có cấu trúc.
Có cần dùng Vnstock để xây harness tài chính không?
Không. Harness là cách tổ chức mục tiêu, quyền, phản hồi và bằng chứng. Vnstock là một lựa chọn công cụ Python cho lớp kết nối và chuẩn hoá dữ liệu; có thể thay bằng công cụ phù hợp khác nếu bài toán yêu cầu.
Kết quả tốt hơn trong backtest có phải lợi thế đầu tư không?
Không. Đó mới là kết quả trên dữ liệu và thiết kế kiểm định đã chọn. Cần kiểm tra ngoài mẫu, độ nhạy với giả định, chi phí và quá trình thử nghiệm trước khi nói đến khả năng sử dụng thực tế.
Tài liệu tham khảo
— Vnstock là hệ sinh thái công cụ Python chạy trên hạ tầng của bạn: kết nối, chuẩn hoá và phân tích dữ liệu thị trường từ nguồn bên thứ ba. Vnstock cấp quyền dùng phần mềm, không bán dữ liệu; tính sẵn sàng và độ chính xác phụ thuộc nguồn. Nội dung phục vụ nghiên cứu và tham khảo, không phải khuyến nghị đầu tư.
Footnotes
-
Andrej Karpathy,
autoresearch— README và mã nguồn, truy cập tháng 09/2026. ↩ ↩2 -
Andrej Karpathy,
program.md— quy trình chạy và ghi thử nghiệm, truy cập tháng 09/2026. ↩ -
Ryan Lopopolo, Harness engineering: leveraging Codex in an agent-first world, OpenAI, 11/02/2026. ↩
-
David H. Bailey, Jonathan Borwein, Marcos López de Prado và Qiji Jim Zhu, The Probability of Backtest Overfitting, Journal of Computational Finance, 2015. ↩
Thảo luận
Đang tải…