{/* Trang này được tạo tự động từ SKILL.md của kỹ năng bởi website/scripts/generate-skill-docs.py. Chỉnh sửa nguồn SKILL.md, không phải trang này. */}
Viết bài nghiên cứu
Viết bài ML cho NeurIPS/ICML/ICLR: thiết kế→gửi.
Siêu dữ liệu kỹ năng
| Nguồn | Đi kèm (được cài đặt theo mặc định) |
| Đường dẫn |
skills/research/research-paper-writing ` | | Phiên bản |
1.1.0 ` | | Tác giả | Nghiên cứu dàn nhạc | | Giấy phép | MIT | | Phụ thuộc |
semanticscholar
, `arxiv
, `habanero
, `requests
, `scipy
, `numpy
, `matplotlib
,
SciencePlots |
| Nền tảng | Linux, macOS |
| Thẻ |
Research
, `Paper Writing
, `Experiments
, `ML
, `AI
, `NeurIPS
, `ICML
, `ICLR
, `ACL
, `AAAI
, `COLM
, `LaTeX
, `Citations
,
Statistical Analysis |
| Kỹ năng liên quan | XPROTECTX105XPROTECTX,
`ml-paper-writing
, XPROTECTX107XPROTECTX, XPROTECTX108XPROTECTX |
Tham khảo: đầy đủ SKILL.md
thông tin
Sau đây là định nghĩa kỹ năng đầy đủ mà Hermes tải khi kỹ năng này được kích hoạt. Đây là những gì tác nhân coi là hướng dẫn khi kỹ năng được kích hoạt.
Quy trình viết bài nghiên cứu
Quy trình toàn diện để tạo ra các tài liệu nghiên cứu ML/AI sẵn sàng xuất bản nhắm mục tiêu NeurIPS, ICML, ICLR, ACL, AAAI và COLM. Kỹ năng này bao gồm toàn bộ vòng đời nghiên cứu: thiết kế thử nghiệm, thực hiện, giám sát, phân tích, viết bài, đánh giá, sửa đổi và nộp.
Đây không phải là một đường dẫn tuyến tính - nó là một vòng lặp. Kết quả kích hoạt các thử nghiệm mới. Đánh giá kích hoạt phân tích mới. Tác nhân phải xử lý các vòng phản hồi này.`<!-- ascii-guard-ignore --> <!-- ascii-guard-ignore -->
`
┌─────────────────────────────────────────────────────────────┐ │ RESEARCH PAPER pipELINE │ │ │ │ Phase 0: Project Setup ──► Phase 1: Literature Review │ │ │ │ │ │ ▼ ▼ │ │ Phase 2: Experiment Phase 5: Paper Drafting ◄──┐ │ │ Design │ │ │ │ │ ▼ │ │ │ ▼ Phase 6: Self-Review │ │ │ Phase 3: Execution & & Revision ──────────┘ │ │ Monitoring │ │ │ │ ▼ │ │ ▼ Phase 7: Submission │ │ Phase 4: Analysis ─────► (feeds back to Phase 2 or 5) │ │ │ └─────────────────────────────────────────────────────────────┘
`
<!-- ascii-guard-ignore-end --> <!-- ascii-guard-ignore-end -->
Khi nào nên sử dụng kỹ năng này
Hãy sử dụng kỹ năng này khi:
- Bắt đầu một bài nghiên cứu mới từ cơ sở mã hoặc ý tưởng hiện có
- Thiết kế và chạy thử nghiệm để hỗ trợ các yêu cầu trên giấy
- Viết hoặc sửa lại bất kỳ phần nào của bài nghiên cứu
- Chuẩn bị đệ trình tới một hội nghị hoặc hội thảo cụ thể
- Phản hồi các bài đánh giá bằng các thử nghiệm hoặc bản sửa đổi bổ sung
- Chuyển đổi bài viết giữa các định dạng hội nghị
- Viết các bài báo phi thực nghiệm — các bài viết về lý thuyết, khảo sát, điểm chuẩn hoặc quan điểm (xem Paper Types Beyond Empirical ML)
- Thiết kế đánh giá con người cho NLP, HCI hoặc nghiên cứu liên kết
- Chuẩn bị các sản phẩm sau khi chấp nhận — áp phích, buổi nói chuyện, phát hành mã
Triết lý cốt lõi
- Hãy chủ động. Cung cấp bản nháp hoàn chỉnh, không đưa ra câu hỏi. Các nhà khoa học đang bận rộn - tạo ra thứ gì đó cụ thể mà họ có thể phản ứng, sau đó lặp lại.
- Không bao giờ gây ảo giác về các trích dẫn. Các trích dẫn do AI tạo ra có tỷ lệ lỗi ~40%. Luôn tìm nạp theo chương trình. Đánh dấu các trích dẫn không thể kiểm chứng là
[CITATION NEEDED]
. 3. Bài viết là một câu chuyện, không phải là tập hợp các thí nghiệm. Mỗi bài viết cần có một đóng góp rõ ràng được nêu trong một câu duy nhất. Nếu bạn không thể làm được điều đó nghĩa là bài báo chưa sẵn sàng. 4. Thử nghiệm đưa ra tuyên bố. Mỗi thử nghiệm phải nêu rõ tuyên bố nào được nó hỗ trợ. Không bao giờ thực hiện các thử nghiệm không kết nối với câu chuyện của bài báo. 5. Cam kết sớm, cam kết thường xuyên. Mỗi đợt thử nghiệm đã hoàn thành, mỗi bản cập nhật dự thảo trên giấy - cam kết kèm theo thông điệp mô tả. Nhật ký Git là lịch sử thử nghiệm.
Tính chủ động và hợp tác`Mặc định: Hãy chủ động. Bản nháp trước, hỏi bản nháp.
| Mức độ tin cậy | Hành động |
|---|---|
| Cao (repo rõ ràng, đóng góp rõ ràng) | Viết bản nháp đầy đủ, phân phối, lặp lại phản hồi |
| Trung bình (một số mơ hồ) | Viết bản nháp với những điểm không chắc chắn được gắn cờ, tiếp tục |
| Thấp (ẩn số lớn) | Đặt 1-2 câu hỏi mục tiêu qua |
| `clarify |
, sau đó soạn thảo |
| Phần | Dự thảo tự chủ? | Cờ có bản nháp |
|---|---|---|
| Tóm tắt | Có | "Đóng góp được đóng khung dưới dạng X — điều chỉnh nếu cần" |
| Giới thiệu | Có | "Nhấn mạnh vấn đề Y — đúng nếu sai" |
| Phương pháp | Có | "Đã bao gồm các chi tiết A, B, C — bổ sung các chi tiết còn thiếu" |
| Thí nghiệm | Có | "Kết quả được đánh dấu 1, 2, 3 — sắp xếp lại nếu cần" |
| Công việc liên quan | Có | "Các bài viết được trích dẫn X, Y, Z — bổ sung những bài tôi bỏ sót" |
Chỉ chặn đầu vào khi: địa điểm mục tiêu không rõ ràng, nhiều khung hình mâu thuẫn, kết quả dường như không đầy đủ, yêu cầu rõ ràng để xem xét trước.
Giai đoạn 0: Thiết lập dự ánMục tiêu: Thiết lập không gian làm việc, hiểu rõ công việc hiện có, xác định sự đóng góp.
Bước 0.1: Khám phá Kho lưu trữ
# Understand project structure
ls -la
find . -name "*.py" | head -30
find . -name "*.md" -o -name "*.txt" | xargs grep -l -i "result\|conclusion\|finding"
`
``Hãy tìm:
-
`README.md
` — tổng quan và tuyên bố về dự án
-
`results/
,
`outputs/
,
`experiments/
` — những phát hiện hiện có
-
`configs/
` — cài đặt thử nghiệm
- Tệp
.bib
- trích dẫn hiện có
- Dự thảo văn bản hoặc ghi chú
### Bước 0.2: Sắp xếp không gian làm việc
Thiết lập cấu trúc không gian làm việc nhất quán:
`
workspace/
paper/ # LaTeX source, figures, compiled PDFs
experiments/ # Experiment runner scripts
code/ # Core method implementation
results/ # Raw experiment results (auto-generated)
tasks/ # Task/benchmark definitions
human_eval/ # Human evaluation materials (if needed)
`
### Bước 0.3: Thiết lập Kiểm soát phiên bản
``` bash
git init # if not already
git remote add origin <repo-url
git checkout -b paper-draft # or main
`
``**Kỷ luật Git**: Mỗi lô thử nghiệm đã hoàn thành đều được cam kết kèm theo một thông báo mô tả. Ví dụ:
`
Add Monte Carlo constrained results (5 runs, Sonnet 4.6, policy memo task)
Add Haiku baseline comparison: autoreason vs refinement baselines at cheap model tier
`
### Bước 0.4: Xác định đóng góp
Trước khi viết bất cứ điều gì, hãy nói rõ:
- **Cái gì**: Điều duy nhất mà bài viết này đóng góp là gì?
- **Tại sao**: Bằng chứng nào chứng minh điều đó?
- **The So What**: Tại sao độc giả nên quan tâm?`> Đề xuất với nhà khoa học: "Theo hiểu biết của tôi, đóng góp chính là: [một câu]. Kết quả then chốt cho thấy [Y]. Đây có phải là khung hình bạn mong muốn không?"
### Bước 0.5: Tạo danh sách TODO
Sử dụng công cụ
`todo
` để tạo kế hoạch dự án có cấu trúc:
`
Research Paper TODO:
- [ ] Define one-sentence contribution
- [ ] Literature review (related work + baselines)
- [ ] Design core experiments
- [ ] Run experiments
- [ ] Analyze results
- [ ] Write first draft
- [ ] Self-review (simulate reviewers)
- [ ] Revise based on review
- [ ] Submission prep
`
``Cập nhật điều này trong suốt dự án. Nó đóng vai trò là trạng thái liên tục trong các phiên.
### Bước 0.6: Ước tính ngân sách tính toán
Trước khi chạy thử nghiệm, hãy ước tính tổng chi phí và thời gian:
`
Compute Budget Checklist:
- [ ] API costs: (model price per token) × (estimated tokens per run) × (number of runs)
- [ ] GPU hours: (time per experiment) × (number of experiments) × (number of seeds)
- [ ] Human evaluation costs: (annotators) × (hours) × (hourly rate)
- [ ] Total budget ceiling and contingency (add 30-50% for reruns)
`
``Theo dõi chi tiêu thực tế khi chạy thử nghiệm:
`
``` python
# Simple cost tracker pattern
import JSON, os
from datetime import datetime
COST_LOG = "results/cost_log.JSONl"`def log_cost(experiment: str, model: str, input_tokens: int, output_tokens: int, cost_usd: float):
entry = {
"timestamp": datetime.now().isoformat(),
"experiment": experiment,
"model": model,
"input_tokens": input_tokens,
"output_tokens": output_tokens,
"cost_usd": cost_usd,
}
with open(COST_LOG, "a") as f:
f.write(JSON.dumps(entry) + "\n")
`
``**Khi ngân sách eo hẹp**: Chạy thử nghiệm thí điểm (1-2 hạt giống, một nhóm nhỏ nhiệm vụ) trước khi tiến hành quét toàn bộ. Sử dụng các mô hình rẻ hơn để gỡ lỗi quy trình, sau đó chuyển sang mô hình mục tiêu cho lần chạy cuối cùng.
### Bước 0.7: Phối hợp nhiều tác giả
Hầu hết các bài báo có 3-10 tác giả. Thiết lập quy trình công việc sớm:
| Quy trình làm việc | Công cụ | Khi nào nên sử dụng |
|----------|------|-------------|
| **Trang bìa** | Dựa trên trình duyệt | Nhiều tác giả chỉnh sửa đồng thời, không có kinh nghiệm git |
| **Git + LaTeX** |
git
` với
.gitignore
` cho các tệp phụ trợ | Đội ngũ kỹ thuật, cần xem xét theo từng chi nhánh |
| **Đồng bộ hóa trang bìa + Git** | Phí bảo hiểm trên trang | Tốt nhất của cả hai - cộng tác trực tiếp với lịch sử phiên bản |
**Quyền sở hữu phần**: Chỉ định mỗi phần cho một tác giả chính. Những người khác bình luận nhưng không chỉnh sửa trực tiếp. Ngăn chặn xung đột hợp nhất và sự không nhất quán về phong cách.
`
Author Coordination Checklist:
- [ ] Agree on section ownership (who writes what)
- [ ] Set up shared workspace (Overleaf or git repo)
- [ ] Establish notation conventions (before anyone writes)
- [ ] Schedule internal review rounds (not just at the end)
- [ ] Designate one person for final formatting pass
- [ ] Agree on figure style (colors, fonts, sizes) before creating figures
`
``**Các quy ước LaTeX cần được thống nhất sớm**:
- Macro
\method\{}
` để đặt tên phương thức nhất quán
- Kiểu trích dẫn: Cách sử dụng
\citet\{}
` so với
\citep\{}
- Ký hiệu toán học: in đậm cho vectơ, in đậm cho ma trận, v.v.
- Chính tả của Anh và Mỹ
---
## Giai đoạn 1: Ôn tập tài liệu`**Mục tiêu**: Tìm công việc liên quan, xác định cơ sở, thu thập trích dẫn.
### Bước 1.1: Xác định Seed Paper
Bắt đầu từ các bài viết đã được tham chiếu trong cơ sở mã:
``` bash
# Via terminal:
grep -r "arxiv\|doi\|cite" --include="*.md" --include="*.bib" --include="*.py"
find . -name "*.bib"
`
### Bước 1.2: Tìm kiếm công việc liên quan`**Tải kỹ năng
`arxiv
** để khám phá giấy có cấu trúc:
`skill_view("arxiv")
. Nó cung cấp tìm kiếm API arXiv REST, biểu đồ trích dẫn Semantic Scholar, hồ sơ tác giả và tạo BibTeX.
Sử dụng
`web_search
` để khám phá rộng rãi,
`web_extract
` để tìm nạp các giấy tờ cụ thể:
`
# Via web_search:
web_search("[main technique] + [application domain] site:arxiv.org")
web_search("[baseline method] comparison ICML NeurIPS 2024")
# Via web_extract (for specific papers):
web_extract("https://arxiv.org/abs/2303.17651")
`
``Truy vấn tìm kiếm bổ sung để thử:
`
Search queries:
- "[main technique] + [application domain]"
- "[baseline method] comparison"
- "[problem name] state-of-the-art"
- Author names from existing citations
`
``**Khuyến nghị**: Cài đặt **Exa MCP** để tìm kiếm học thuật theo thời gian thực:
`
``` bash
Claude MCP add exa -- npx -y MCP-remote "https://MCP.exa.ai/MCP"
`
### Bước 1.2b: Tìm kiếm sâu hơn (Chiều rộng, sau đó là Chiều sâu)
Tìm kiếm phẳng (một vòng truy vấn) thường bỏ sót nội dung quan trọng có liên quan. Sử dụng mẫu **rộng rồi sâu** lặp lại lấy cảm hứng từ quy trình nghiên cứu sâu:
`
Iterative Literature Search:
Round 1 (Breadth): 4-6 parallel queries covering different angles
- "[method] + [domain]"
- "[problem name] state-of-the-art 2024 2025"
- "[baseline method] comparison"
- "[alternative approach] vs [your approach]"
→ Collect papers, extract key concepts and terminology
Round 2 (Depth): Generate follow-up queries from Round 1 learnings
- New terminology discovered in Round 1 papers
- Papers cited by the most relevant Round 1 results
- Contradictory findings that need investigation
→ Collect papers, identify remaining gaps
Round 3 (Targeted): Fill specific gaps
- Missing baselines identified in Rounds 1-2
- Concurrent work (last 6 months, same problem)
- Key negative results or failed approaches
→ Stop when new queries return mostly papers you've already seen
`
``**Khi nào nên dừng**: Nếu một vòng trả về >80% số giấy tờ đã có trong bộ sưu tập của bạn thì tìm kiếm đã bão hòa. Thông thường 2-3 vòng là đủ. Đối với các bài khảo sát, dự kiến sẽ có 4-5 vòng.
**Đối với quy trình làm việc dựa trên tác nhân**: Ủy quyền song song các truy vấn của từng vòng thông qua
`delegate_task
. Thu thập kết quả, loại bỏ trùng lặp, sau đó tạo các truy vấn của vòng tiếp theo từ các bài học tổng hợp.
### Bước 1.3: Xác minh mọi trích dẫn`**KHÔNG BAO GIỜ tạo BibTeX từ bộ nhớ. LUÔN tìm nạp theo chương trình.**
Đối với mỗi trích dẫn, hãy làm theo quy trình 5 bước bắt buộc:
`
Citation Verification (MANDATORY per citation):
1. SEARCH → Query Semantic Scholar or Exa MCP with specific keywords
2. VERIFY → Confirm paper exists in 2+ sources (Semantic Scholar + arXiv/CrossRef)
3. RETRIEVE → Get BibTeX via DOI content negotiation (programmatically, not from memory)
4. VALIDATE → Confirm the claim you're citing actually appears in the paper
5. ADD → Add verified BibTeX to bibliography
If ANY step fails → mark as [CITATION NEEDED], inform scientist
`
`
``` python
# Fetch BibTeX via DOI
import requests`def doi_to_bibtex(doi: str) -> str:
response = requests.get(
f"https://doi.org/\{doi}",
headers=\{"Accept": "application/x-bibtex"}
)
response.raise_for_status()
return response.text
`
``Nếu bạn không thể xác minh một trích dẫn:
`latex
\cite\{PLACEHOLDER_author2024_verify_this} % TODO: Verify this citation exists
`
``**Luôn nói với nhà khoa học**: "Tôi đã đánh dấu [X] trích dẫn là phần giữ chỗ cần xác minh."
Xem [references/citation-workflow.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/skills/research/research-paper-writing/references/citation-workflow.md) để biết tài liệu API đầy đủ và lớp
`CitationManager
` đầy đủ.
### Bước 1.4: Sắp xếp công việc liên quanNhóm các bài viết theo phương pháp, không phải từng tờ giấy:
**Tốt**: "Một dòng công việc sử dụng giả định của X [refs] trong khi chúng tôi sử dụng giả định của Y vì..."
**Xấu**: "Smith và cộng sự đã giới thiệu X. Jones và cộng sự đã giới thiệu Y. Chúng tôi kết hợp cả hai."
---
## Giai đoạn 2: Thiết kế thí nghiệm`**Mục tiêu**: Thiết kế các thử nghiệm hỗ trợ trực tiếp cho các tuyên bố trên giấy. Mỗi thí nghiệm phải trả lời một câu hỏi cụ thể.
### Bước 2.1: Ánh xạ các xác nhận quyền sở hữu tới các thử nghiệm
Tạo một ánh xạ rõ ràng:
| Yêu cầu | Thí nghiệm | Bằng chứng dự kiến |
|-------|----------||-------------------|
| "Phương pháp của chúng tôi vượt trội so với đường cơ sở" | So sánh chính (Bảng 1) | Tỷ lệ thắng, ý nghĩa thống kê |
| "Hiệu quả lớn hơn đối với các mẫu máy yếu hơn" | Nghiên cứu nhân rộng mô hình | Đường cong cải tiến đơn điệu |
| "Hội tụ yêu cầu hạn chế về phạm vi" | Bị ràng buộc và không bị ràng buộc | So sánh tốc độ hội tụ |
**Quy tắc**: Nếu một thử nghiệm không ánh xạ tới một xác nhận quyền sở hữu thì đừng chạy thử nghiệm đó.
### Bước 2.2: Thiết kế đường cơ sở
Đường cơ sở vững chắc là yếu tố phân biệt các bài viết được chấp nhận với những bài bị từ chối. Người đánh giá sẽ hỏi: "Họ có so sánh với X không?"
Các loại đường cơ sở tiêu chuẩn:
- **Đường cơ sở ngây thơ**: Cách tiếp cận đơn giản nhất có thể
- **Cơ sở vững chắc**: Phương pháp hiện có được biết đến nhiều nhất
- **Các đường cơ sở cắt bỏ**: Phương pháp của bạn trừ đi một thành phần
- **Các đường cơ sở tính toán phù hợp**: Ngân sách tính toán giống nhau, phân bổ khác nhau
### Bước 2.3: Xác định quy trình đánh giá
Trước khi chạy bất cứ điều gì, hãy chỉ định:
- **Số liệu**: Những gì bạn đang đo, ký hiệu chỉ hướng (cao hơn/thấp hơn tốt hơn)
- **Tổng hợp**: Cách kết hợp các kết quả trên các lần chạy/nhiệm vụ
- **Kiểm tra thống kê**: Những kiểm tra nào sẽ xác định ý nghĩa
- **Cỡ mẫu**: Số lần chạy/vấn đề/tác vụ
### Bước 2.4: Viết kịch bản thử nghiệm
Thực hiện theo các mô hình sau từ các quy trình nghiên cứu thành công:
**Tiết kiệm gia tăng** — lưu kết quả sau mỗi bước để khắc phục sự cố:
`
``` python
# Save after each problem/task
result_path = f"results/\{task}/\{strategy}/result.JSON"
if os.path.exists(result_path):
Continue # Skip already-completed work
# ... run experiment ...
with open(result_path, 'w') as f:
JSON.dump(result, f, indent=2)
`
``**Bảo quản hiện vật** — lưu tất cả các kết quả đầu ra trung gian:
`
results/<experiment>/
<task>/
<strategy>/
final_output.md # Final result
history.JSON # Full trajectory
pass_01/ # Per-iteration artifacts
version_a.md
version_b.md
critic.md
`
``**Tách biệt các mối quan tâm** — tách biệt việc tạo, đánh giá và trực quan hóa:
`
run_experiment.py # Core experiment runner
run_baselines.py # Baseline comparison
run_comparison_judge.py # Blind evaluation
analyze_results.py # Statistical analysis
make_charts.py # Visualization
`
``Xem [references/experiment-patterns.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/skills/research/research-paper-writing/references/experiment-patterns.md) để biết các mẫu thiết kế hoàn chỉnh, giám sát cron và khắc phục lỗi.
### Bước 2.5: Thiết kế đánh giá con người (Nếu có)
Nhiều bài viết về NLP, HCI và căn chỉnh yêu cầu đánh giá của con người làm bằng chứng chính hoặc bổ sung. Hãy thiết kế điều này trước khi chạy thử nghiệm tự động — việc đánh giá con người thường có thời gian thực hiện lâu hơn (phê duyệt IRB, tuyển dụng người chú thích).
**Khi cần có sự đánh giá của con người:**
- Số liệu tự động không nắm bắt được điều bạn quan tâm (sự trôi chảy, hữu ích, an toàn)
- Đóng góp của bạn là về phẩm chất đối diện với con người (khả năng đọc, sở thích, sự tin cậy)
- Người đánh giá tại các địa điểm NLP (ACL, EMNLP) mong đợi nó cho các nhiệm vụ tạo`**Các quyết định thiết kế chính:**
| Quyết định | Tùy chọn | Hướng dẫn |
|----------|----------|----------|
| **Loại chú thích** | Chuyên gia, cộng tác viên, người dùng cuối | Phù hợp với yêu cầu của bạn |
| **Tỷ lệ** | Likert (1-5), so sánh từng cặp, xếp hạng | Pairwise đáng tin cậy hơn Likert cho đầu ra LLM |
| **Cỡ mẫu** | Mỗi người chú thích và tổng số mục | Phân tích sức mạnh hoặc tối thiểu 100 mục, hơn 3 người chú thích |
| **Số liệu thỏa thuận** | Cohen's kappa, Krippendorff's alpha, ICC | Krippendorff's alpha cho >2 người chú thích; báo cáo thỏa thuận thô quá |
| **Nền tảng** | Sung mãn, MTurk, nhóm nội bộ | Sung mãn về chất lượng; MTurk cho quy mô; nội bộ về chuyên môn miền |
**Danh sách kiểm tra hướng dẫn chú thích:**
`
- [ ] Clear task description with examples (good AND bad)
- [ ] Decision criteria for ambiguous cases
- [ ] At least 2 worked examples per category
- [ ] Attention checks / gold standard items (10-15% of total)
- [ ] Qualification task or screening round
- [ ] Estimated time per item and fair compensation (>= local minimum wage)
- [ ] IRB/ethics review if required by your institution
`
``**Yêu cầu báo cáo** (người đánh giá kiểm tra tất cả những điều này):
- Số lượng người chú thích và trình độ của họ
- Thỏa thuận giữa các nhà chú thích với số liệu và giá trị cụ thể
- Chi tiết bồi thường (số tiền, tỷ lệ hàng giờ ước tính)
- Mô tả giao diện chú thích hoặc ảnh chụp màn hình (phụ lục)
- Tổng thời gian chú thích
Xem [references/human-evaluation.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/skills/research/research-paper-writing/references/human-evaluation.md) để biết hướng dẫn đầy đủ bao gồm các bài kiểm tra thống kê về dữ liệu đánh giá của con người, các mẫu kiểm soát chất lượng nguồn lực cộng đồng và hướng dẫn IRB.
---
## Giai đoạn 3: Thực hiện & Giám sát Thử nghiệm`**Mục tiêu**: Chạy thử nghiệm một cách đáng tin cậy, theo dõi tiến độ, phục hồi sau thất bại.
### Bước 3.1: Khởi chạy thử nghiệm
Sử dụng
`nohup
` cho các thử nghiệm kéo dài:
``` bash
nohup Python run_experiment.py --config config.yaml > logs/experiment_01.log 2>&1 &
echo $! # Record the PID
`
``**Thực thi song song**: Chạy đồng thời các thử nghiệm độc lập nhưng lưu ý đến giới hạn tốc độ API. Hơn 4 thử nghiệm đồng thời trên cùng một API sẽ làm chậm mỗi thử nghiệm.
### Bước 3.2: Thiết lập giám sát (Cron Pattern)
Đối với các thử nghiệm kéo dài, hãy thiết lập kiểm tra trạng thái định kỳ. Dấu nhắc cron phải tuân theo mẫu này:
`
Monitor Prompt Template:
1. Check if process is still running: ps aux | grep <pattern>
2. Read last 30 lines of log: tail -30 <logfile>
3. Check for completed results: ls <result_dir>
4. If results exist, read and report: cat <result_file>
5. If all done, commit: git add -A && git commit -m "<descriptive message>" && git push
6. Report in structured format (tables with key metrics)
7. Answer the key analytical question for this experiment
`
`**Chế độ im lặng**: Nếu không có gì thay đổi kể từ lần kiểm tra cuối cùng, hãy phản hồi bằng
[SILENT]
` để chặn thông báo tới người dùng. Chỉ đưa tin khi có tin tức.
### Bước 3.3: Xử lý lỗi
Các chế độ lỗi phổ biến và phục hồi:
| Thất bại | Phát hiện | Phục hồi |
|----------|-------------|----------|
| Giới hạn tỷ lệ API / cạn kiệt tín dụng | Lỗi 402/429 trong nhật ký | Đợi rồi chạy lại (tập lệnh bỏ qua công việc đã hoàn thành) |
| Quá trình gặp sự cố | PID biến mất, kết quả không đầy đủ | Chạy lại từ điểm kiểm tra cuối cùng |
| Hết giờ đối với các bài toán khó | Quá trình bị kẹt, không có tiến trình đăng nhập | Giết và bỏ qua, ghi lại kết quả |
| ID mẫu sai | Lỗi tham chiếu tên model | Sửa ID và chạy lại |
**Khóa**: Tập lệnh phải luôn kiểm tra kết quả hiện có và bỏ qua công việc đã hoàn thành. Điều này làm cho việc chạy lại an toàn và hiệu quả.
### Bước 3.4: Cam kết kết quả hoàn thành
Sau khi mỗi đợt thử nghiệm hoàn thành:
``` bash
git add -A
git commit -m "Add <experiment name>: <key finding in 1 line>"
git push
`
### Bước 3.5: Duy trì nhật ký thí nghiệm
Git cam kết theo dõi những gì đã xảy ra, chứ không phải **cây khám phá** — các quyết định về những gì cần thử tiếp theo dựa trên những gì bạn đã học được. Duy trì một nhật ký thử nghiệm có cấu trúc để ghi lại cây này:
`JSON
// experiment_journal.JSONl — append one entry per experiment attempt
{
"id": "exp_003",
"parent": "exp_001",
"timestamp": "2025-05-10T14:30:00Z",
"hypothesis": "Adding scope constraints will fix convergence failure from exp_001",
"plan": "Re-run autoreason with max_tokens=2000 and fixed structure template",
"config": \{"model": "haiku", "strategy": "autoreason", "max_tokens": 2000},
"status": "completed",
"result_path": "results/exp_003/",
"key_metrics": \{"win_rate": 0.85, "convergence_rounds": 3},
"analysis": "Scope constraints fixed convergence. Win rate jumped from 0.42 to 0.85.",
"next_steps": ["Try same constraints on Sonnet", "Test without structure template"],
"figures": ["figures/exp003_convergence.pdf"]
}
`
``**Tại sao lại là nhật ký, không phải chỉ git?** Git theo dõi các thay đổi của tệp. Nhật ký theo dõi lý do: tại sao bạn thử X, bạn đã học được điều gì và điều đó có ý nghĩa gì đối với thử nghiệm tiếp theo. Khi viết bài báo, cây này rất có giá trị đối với phần Phương pháp ("chúng tôi đã quan sát X, điều này thúc đẩy Y") và để báo cáo thất bại một cách trung thực.
**Chọn đường dẫn tốt nhất**: Khi tạp chí hiển thị cây phân nhánh (exp_001 → exp_002a, exp_002b, exp_003), hãy xác định đường dẫn hỗ trợ tốt nhất cho tuyên bố của bài báo. Ghi lại các nhánh cụt trong phần phụ lục dưới dạng cắt bỏ hoặc kết quả âm tính.
**Ảnh chụp nhanh mã cho mỗi thử nghiệm**: Sao chép tập lệnh thử nghiệm sau mỗi lần chạy:
`
`bash
cp experiment.py results/exp_003/experiment_snapshot.py
`
Điều này cho phép tái tạo chính xác ngay cả sau khi thay đổi mã tiếp theo.
---
## Giai đoạn 4: Phân tích kết quả`**Mục tiêu**: Trích xuất các phát hiện, tính toán số liệu thống kê, xác định câu chuyện.
### Bước 4.1: Kết quả tổng hợp
Viết kịch bản phân tích:
1. Tải tất cả các tệp kết quả từ một đợt
2. Tính toán số liệu theo từng nhiệm vụ và tổng hợp
3. Tạo bảng tóm tắt
``` python
# Standard analysis pattern
import JSON, os
from pathlib import Path`results = \{}
for result_file in Path("results/").rglob("result.JSON"):
data = JSON.loads(result_file.read_text())
strategy = result_file.parent.name
task = result_file.parent.parent.name
results.setdefault(strategy, \{})[task] = data
# Compute aggregate metrics
for strategy, tasks in results.items():
scores = [t["score"] for t in tasks.values()]
print(f"\{strategy}: mean=\{np.mean(scores):.1f}, std=\{np.std(scores):.1f}")
`
### Bước 4.2: Ý nghĩa thống kê
Luôn tính toán:
- **Thanh lỗi**: Độ lệch chuẩn hoặc sai số chuẩn, chỉ rõ lỗi nào
- **Khoảng tin cậy**: 95% CI cho kết quả chính
- **Kiểm tra theo cặp**: Kiểm định của McNemar để so sánh hai phương pháp
- **Kích thước hiệu ứng**: Cohen's d hoặc h có ý nghĩa thực tế
Xem [references/experiment-patterns.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/skills/research/research-paper-writing/references/experiment-patterns.md) để biết cách triển khai đầy đủ thử nghiệm của McNemar, các CI đã khởi động và mã h.
### Bước 4.3: Xác định câu chuyện
Sau khi phân tích hãy trả lời rõ ràng:
1. **Phát hiện chính là gì?** Trình bày nó trong một câu.
2. **Điều gì làm bạn ngạc nhiên?** Những kết quả bất ngờ thường tạo nên những bài báo hay nhất.
3. **Điều gì đã thất bại?** Những thử nghiệm thất bại có thể mang lại nhiều thông tin hữu ích nhất. Báo cáo trung thực về những thất bại củng cố bài viết.
4. **Cần những thử nghiệm tiếp theo nào?** Kết quả thường đặt ra những câu hỏi mới.
#### Xử lý kết quả âm tính hoặc không
Khi giả thuyết của bạn sai hoặc kết quả không thuyết phục, bạn có ba lựa chọn:
| Tình huống | Hành động | Địa điểm phù hợp |
|----------|--------|----------|
| Giả thuyết sai nhưng **tại sao** lại có nhiều thông tin | Khung giấy xung quanh việc phân tích lý do tại sao | NeurIPS, ICML (nếu phân tích nghiêm ngặt) |
| Phương pháp này không vượt qua được đường cơ sở nhưng **tiết lộ điều gì đó mới** | Điều chỉnh lại đóng góp dưới dạng hiểu biết/phân tích | ICLR (hiểu biết giá trị), tài liệu hội thảo |
| Kết quả âm tính rõ ràng theo yêu cầu phổ biến | Viết lên - lĩnh vực cần biết | Bộ dữ liệu & điểm chuẩn NeurIPS, TMLR, hội thảo |
| Kết quả không thuyết phục, không có câu chuyện rõ ràng | Pivot — chạy các thử nghiệm khác nhau hoặc điều chỉnh lại | Đừng ép một tờ giấy không có |
**Cách viết bài báo kết quả âm tính:**
- Dẫn đầu với những gì cộng đồng tin tưởng và lý do tại sao việc kiểm tra nó lại quan trọng
- Mô tả phương pháp luận nghiêm ngặt của bạn (phải kín đáo - người đánh giá sẽ xem xét kỹ lưỡng hơn)
- Trình bày kết quả null rõ ràng bằng bằng chứng thống kê
- Phân tích **tại sao** kết quả mong đợi không thành hiện thực
- Thảo luận ý nghĩa của lĩnh vực này`**Các địa điểm hoan nghênh rõ ràng các kết quả tiêu cực**: NeurIPS (Theo dõi bộ dữ liệu & điểm chuẩn), TMLR, Thử thách khả năng tái tạo ML, hội thảo tại các hội nghị lớn. Một số hội thảo đặc biệt kêu gọi kết quả tiêu cực.
### Bước 4.4: Tạo Hình và Bảng**Số liệu**:
- Sử dụng đồ họa vector (PDF) cho tất cả các ô:
`plt.savefig('fig.pdf')
- Bảng màu an toàn cho người mù màu (Okabe-Ito hoặc Paul Tol)
- Chú thích khép kín — người đọc có thể hiểu mà không cần nội dung chính
- Không có tiêu đề bên trong hình — chú thích phục vụ chức năng này`**Bàn**:
- Sử dụng gói
`booktabs
` LaTeX
- In đậm giá trị tốt nhất cho mỗi số liệu
- Bao gồm các ký hiệu hướng (cao hơn/thấp hơn tốt hơn)
- Độ chính xác thập phân nhất quán
`latex
\usepackage\{booktabs}
\begin\{tabular}\{lcc}
\toprule
Method & Accuracy $\uparrow$ & Latency $\downarrow$ \\
\midrule
Baseline & 85.2 & 45ms \\
\textbf\{Ours} & \textbf\\{92.1} & 38ms \\
\bottomrule
\end\{tabular}
`
### Bước 4.5: Quyết định: Thử nghiệm thêm hay viết?
| Tình huống | Hành động |
|----------||--------|
| Tuyên bố cốt lõi được hỗ trợ, kết quả đáng kể | Chuyển sang Giai đoạn 5 (viết) |
| Kết quả chưa thuyết phục, cần thêm dữ liệu | Quay lại Giai đoạn 2 (thiết kế) |
| Phát hiện bất ngờ gợi ý hướng đi mới | Quay lại Giai đoạn 2 (thiết kế) |
| Thiếu một người đánh giá cắt bỏ sẽ yêu cầu | Chạy nó rồi đến Giai đoạn 5 |
| Tất cả các thử nghiệm đã được thực hiện nhưng một số thất bại | Lưu ý thất bại, chuyển sang Giai đoạn 5 |
### Bước 4.6: Viết Nhật ký thí nghiệm (Bridge to Writeup)
Trước khi chuyển sang viết giấy, hãy tạo một nhật ký thử nghiệm có cấu trúc để kết nối các kết quả với văn xuôi. Đây là mô liên kết quan trọng nhất giữa các thử nghiệm và bản ghi - nếu không có nó, tác nhân viết phải lấy lại câu chuyện từ các tệp kết quả thô.
**Tạo
`experiment_log.md
** với cấu trúc như sau:
`markdown
# Experiment Log
## Contribution (one sentence)
[The paper's main claim]
## Experiments Run
### Experiment 1: [Name]
- **Claim tested**: [Which paper claim this supports]
- **Setup**: [Model, dataset, config, number of runs]
- **Key result**: [One sentence with the number]
- **Result files**: results/exp1/final_info.JSON
- **Figures generated**: figures/exp1_comparison.pdf
- **Surprising findings**: [Anything unexpected]
### Experiment 2: [Name]
...
## Figures
| Filename | Description | Which section it belongs in |
|----------|-------------|---------------------------|
| figures/main_comparison.pdf | Bar chart comparing all methods on benchmark X | Results, Figure 2 |
| figures/ablation.pdf | Ablation removing components A, B, C | Results, Figure 3 |
...
## Failed Experiments (document for honesty)
- [What was tried, why it failed, what it tells us]
## Open Questions
- [Anything the results raised that the paper should address]
`
``**Tại sao điều này lại quan trọng**: Khi soạn thảo, tổng đài viên (hoặc đại lý phụ được ủy quyền) có thể tải
`experiment_log.md
` cùng với mẫu LaTeX và tạo bản nháp đầu tiên dựa trên kết quả thực tế. Nếu không có cầu nối này, tác nhân viết phải phân tích các tệp JSON/CSV thô và suy ra câu chuyện — một nguồn phổ biến của các con số bị ảo giác hoặc bị báo cáo sai.
**Kỷ luật Git**: Cam kết nhật ký này cùng với các kết quả mà nó mô tả.
---
## Tinh chỉnh lặp đi lặp lại: Lựa chọn chiến lược
Bất kỳ đầu ra nào trong quy trình này - bản thảo giấy, kịch bản thử nghiệm, phân tích - đều có thể được tinh chỉnh lặp đi lặp lại. Nghiên cứu lý do tự động cung cấp bằng chứng thực nghiệm về thời điểm mỗi chiến lược sàng lọc hoạt động và khi nào nó thất bại. Sử dụng phần này để chọn cách tiếp cận phù hợp.
### Bảng quyết định nhanh
| Tình huống của bạn | Chiến lược | Tại sao |
|--------------|----------|------|
| Mô hình cấp trung + nhiệm vụ hạn chế | **Tự động** | Điểm ngọt ngào. Khoảng cách đánh giá thế hệ là lớn nhất. Đường cơ sở tích cực phá hủy kết quả đầu ra của mô hình yếu. |
| Mô hình hạng trung + nhiệm vụ mở | **Autoreason** với các ràng buộc về phạm vi được thêm vào | Thêm các sự kiện, cấu trúc cố định hoặc có thể phân phối để giới hạn không gian cải tiến. |
| Mô hình biên giới + nhiệm vụ ràng buộc | **Tự động** | Giành được 2/3 nhiệm vụ bị hạn chế ngay cả ở biên giới. |
| Mô hình biên giới + nhiệm vụ không giới hạn | **Phê bình và sửa đổi** hoặc **đạt một lần** | Autoreason đến cuối cùng. Người mẫu tự đánh giá đủ tốt. |
| Nhiệm vụ kỹ thuật cụ thể (thiết kế hệ thống) | **Phê bình và sửa đổi** | Vòng lặp tìm và sửa trực tiếp hiệu quả hơn. |
| Nhiệm vụ điền mẫu (một cấu trúc đúng) | **Đạt một lần** hoặc **bảo thủ** | Không gian quyết định tối thiểu Lặp lại không thêm giá trị. |
| Mã với các trường hợp thử nghiệm | **Autoreason (biến thể mã)** | Phân tích có cấu trúc về *tại sao* nó không thành công trước khi sửa. Tỷ lệ thu hồi 62% so với 43%. |
| Model rất yếu (lớp Llama 8B) | **Vé đơn** | Mô hình quá yếu cho các ứng viên đa dạng. Đầu tư vào chất lượng thế hệ. |
### Khoảng cách đánh giá thế hệ`**Thông tin chi tiết cốt lõi**: Giá trị của Autoreason phụ thuộc vào khoảng cách giữa khả năng tạo mô hình và khả năng tự đánh giá của mô hình đó.`<!-- ascii-guard-ignore -->
`
Model Tier │ Generation │ Self-Eval │ Gap │ Autoreason Value
──────────────────┼────────────┼───────────┼────────┼─────────────────
Weak (Llama 8B) │ Poor │ Poor │ Small │ None — can't generate diverse candidates
Mid (Haiku 3.5) │ Decent │ Poor │ LARGE │ MAXIMUM — 42/42 perfect Borda
Mid (Gemini Flash)│ Decent │ Moderate │ Large │ High — wins 2/3
Strong (Sonnet 4) │ Good │ Decent │ Medium │ Moderate — wins 3/5
Frontier (S4.6) │ Excellent │ Good │ Small │ Only with constraints
`
<!-- ascii-guard-ignore-end -->
Khoảng cách này mang tính cấu trúc, không phải tạm thời. Khi chi phí giảm xuống, phân khúc hàng đầu của ngày hôm nay sẽ trở thành phân khúc tầm trung của ngày mai. Điểm ngọt ngào di chuyển nhưng không bao giờ biến mất.
### Vòng lặp Autoreason (Tóm tắt)
Mỗi lượt tạo ra ba ứng cử viên từ các đặc vụ mới, bị cô lập:
1. **Nhà phê bình** → phát hiện vấn đề ở người đương nhiệm A (không có cách khắc phục)
2. **Tác giả B** → sửa lại A dựa trên lời phê bình
3. **Bộ tổng hợp** → hợp nhất A và B (nhãn ngẫu nhiên)
4. **Hội đồng giám khảo** → 3 giám khảo mù CoT xếp hạng A, B, AB thông qua số lượng Borda
5. **Hội tụ** → A thắng k=2 lần chuyền liên tiếp → xong`**Thông số chính:**
- k=2 hội tụ (k=1 sớm, k=3 quá đắt, không tăng chất lượng)
- CoT luôn đánh giá (hội tụ nhanh hơn gấp 3 lần)
- Nhiệt độ 0,8 tác giả, 0,3 giám khảo
- Tiebreak bảo thủ: đội đương nhiệm thắng hòa
- Mỗi vai trò là một tác nhân mới không có bối cảnh chung
### Áp dụng cho bản nháp giấyKhi tự tinh chỉnh giấy thông qua autoreason:
- **Cung cấp sự thật cơ bản cho người phê bình**: dữ liệu thử nghiệm thực tế, kết quả JSON, kết quả thống kê. Nếu không có điều này, các mô hình sẽ tạo ra các nghiên cứu cắt bỏ bịa đặt và khoảng tin cậy giả mạo.
- **Sử dụng tối thiểu 3 giám khảo làm việc**: Trình phân tích cú pháp đánh giá bị hỏng sẽ không thêm tiếng ồn — nó ngăn chặn hoàn toàn trạng thái cân bằng.
- **Phạm vi hạn chế sửa đổi**: "Giải quyết những điểm yếu cụ thể này" chứ không phải "cải thiện bài viết."
### Chế độ lỗi
| Thất bại | Phát hiện | Sửa chữa |
|----------|-------------|------|
| Không hội tụ (A không bao giờ thắng) | A thắng <15% sau hơn 20 đường chuyền | Thêm các ràng buộc về phạm vi vào nhiệm vụ |
| Trôi tổng hợp | Số từ tăng lên không giới hạn | Cấu trúc hạn chế và khả năng cung cấp |
| Sự xuống cấp dưới một lần | Điểm cơ bản cao hơn kết quả lặp lại | Chuyển sang đường chuyền đơn; mô hình có thể quá yếu |
| Trang bị quá mức (mã) | Đạt bài kiểm tra công khai cao, đạt bài kiểm tra riêng thấp | Sử dụng phân tích có cấu trúc, không chỉ kiểm tra phản hồi |
| Thẩm phán hỏng | Lỗi phân tích cú pháp làm giảm bảng điều khiển xuống dưới 3 | Sửa trình phân tích cú pháp trước khi tiếp tục |
Xem [references/autoreason-methodology.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/skills/research/research-paper-writing/references/autoreason-methodology.md) để biết lời nhắc đầy đủ, chi tiết tính điểm Borda, hướng dẫn lựa chọn mô hình, mẫu thiết kế ràng buộc phạm vi và tham chiếu ngân sách tính toán.
---
## Giai đoạn 5: Soạn thảo giấy`**Mục tiêu**: Viết một bài báo hoàn chỉnh, sẵn sàng xuất bản.
### Quản lý bối cảnh cho các dự án lớn
Một dự án giấy với hơn 50 tệp thử nghiệm, nhiều thư mục kết quả và ghi chú tài liệu phong phú có thể dễ dàng vượt quá cửa sổ ngữ cảnh của tác nhân. Quản lý việc này một cách chủ động:
**Nội dung cần tải vào ngữ cảnh cho mỗi tác vụ soạn thảo:**
| Nhiệm vụ soạn thảo | Tải vào bối cảnh | KHÔNG tải |
|--------------|-------------------|-------------|
| Viết Giới thiệu |
experiment_log.md
, tuyên bố đóng góp, 5-10 tóm tắt bài viết phù hợp nhất | JSON kết quả thô, tập lệnh thử nghiệm đầy đủ, tất cả ghi chú tài liệu |
| Phương pháp viết | Cấu hình thử nghiệm, mã giả, mô tả kiến trúc | Nhật ký thô, kết quả từ các thử nghiệm khác |
| Viết kết quả |
experiment_log.md
, bảng tóm tắt kết quả, danh sách hình | Kịch bản phân tích đầy đủ, dữ liệu trung gian |
| Viết công việc liên quan | Ghi chú trích dẫn có tổ chức (Đầu ra Bước 1.4), tệp .bib | Tệp thử nghiệm, tệp PDF thô |
| Thẻ sửa đổi | Bản thảo toàn văn, mối quan tâm phản biện cụ thể | Mọi thứ khác |
**Nguyên tắc:**
- **
`experiment_log.md
` là cầu nối ngữ cảnh chính** — nó tóm tắt mọi thứ cần thiết để ghi mà không cần tải các tệp dữ liệu thô (xem Bước 4.6)
- **Tải ngữ cảnh của từng phần một** khi ủy quyền. Phương pháp soạn thảo của tác nhân phụ không cần ghi chú đánh giá tài liệu.
- **Tóm tắt, không bao gồm các tệp thô.** Để có kết quả JSON dài 200 dòng, hãy tải bảng tóm tắt 10 dòng. Đối với một bài viết liên quan dài 50 trang, hãy tải bản tóm tắt 5 câu + ghi chú 2 dòng của bạn về mức độ liên quan của nó.
- **Đối với các dự án rất lớn**: Tạo thư mục
`context/
` với các bản tóm tắt được nén sẵn:
`
context/
contribution.md # 1 sentence
experiment_summary.md # Key results table (from experiment_log.md)
literature_map.md # OrganiZed citation notes
figure_inventory.md # List of figures with descriptions
### Nguyên tắc tường thuật`**Thông tin chi tiết quan trọng nhất**: Bài viết của bạn không phải là một tập hợp các thí nghiệm - đó là một câu chuyện với một đóng góp rõ ràng được hỗ trợ bởi bằng chứng.
Mọi bài báo ML thành công đều tập trung vào điều mà Neel Nanda gọi là "câu chuyện": một câu chuyện kỹ thuật ngắn gọn, chặt chẽ, dựa trên bằng chứng với nội dung rút ra mà độc giả quan tâm.
**Ba Trụ cột (phải rõ ràng khi kết thúc phần giới thiệu):**
| Trụ cột | Mô tả | Kiểm tra |
|--------|-------------|------|
| **Cái gì** | 1-3 tuyên bố mới lạ cụ thể | Bạn có thể nêu chúng trong một câu? |
| **Tại sao** | Bằng chứng thực nghiệm nghiêm ngặt | Các thí nghiệm có phân biệt được giả thuyết của bạn với các giải pháp thay thế không? |
| **Vậy thì sao** | Tại sao độc giả nên quan tâm | Điều này có liên quan đến một vấn đề cộng đồng đã được công nhận không? |
**Nếu bạn không thể nêu rõ đóng góp của mình trong một câu thì bạn chưa có bài báo.**
### Nguồn đằng sau hướng dẫn này
Kỹ năng này tổng hợp triết lý viết lách của các nhà nghiên cứu đã xuất bản rộng rãi ở các địa điểm hàng đầu. Lớp triết lý viết ban đầu được [Orchestra Research](https://GitHub.com/orchestra-research) biên soạn dưới dạng kỹ năng
`ml-paper-writing
.| Nguồn | Đóng góp chính | Liên kết |
|--------|-------------------|------|
| **Neel Nanda** (Google DeepMind) | Nguyên tắc tường thuật, Cái gì/Tại sao/Vậy Khuôn khổ gì | [How to Write ML Papers](https://www.alignmentforum.org/posts/eJGPTPbbFPZGLpjsp/highly-opinionated-advice-on-how-to-write-ml-papers) |
| **Sebastian Farquhar** (DeepMind) | công thức trừu tượng 5 câu | [How to Write ML Papers](https://sebastianfarquhar.com/on-research/2024/11/04/how_to_write_ml_papers/) |
| **Gopen & Swan** | 7 nguyên tắc kỳ vọng của độc giả | [Science of Scientific Writing](https://cseweb.ucsd.edu/~swanson/papers/science-of-writing.pdf) |
| **Zachary Lipton** | Lựa chọn từ ngữ, loại bỏ phòng ngừa rủi ro | [Heuristics for Scientific Writing](https://www.approximatelycorrect.com/2018/01/29/heuristics-technical-scientific-writing-machine-learning-perspective/) |
| **Jacob Steinhardt** (UC Berkeley) | Thuật ngữ chính xác, nhất quán | [Writing Tips](https://bounded-regret.ghost.io/) |
| **Ethan Perez** (Anthropic) | Mẹo làm rõ ở cấp độ vi mô | [Easy Paper Writing Tips](https://ethanperez.net/easy-paper-writing-tips/) |
| **Andrej Karpathy** | Trọng tâm đóng góp duy nhất | Bài giảng khác nhau |
**Để tìm hiểu sâu hơn về bất kỳ nội dung nào trong số này, hãy xem:**
- [references/writing-guide.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/skills/research/research-paper-writing/references/writing-guide.md) - Giải thích đầy đủ kèm theo ví dụ
- [references/sources.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/skills/research/research-paper-writing/references/sources.md) — Thư mục hoàn chỉnh
### Phân bổ thời gian
Dành khoảng **thời gian bằng nhau** cho mỗi việc:
1. Tóm tắt
2. Phần giới thiệu
3. Các số liệu
4. Mọi thứ khác kết hợp lại`**Tại sao?** Hầu hết người đánh giá đều đưa ra đánh giá trước khi tiếp cận phương pháp của bạn. Người đọc sẽ gặp bài viết của bạn dưới dạng: tiêu đề → tóm tắt → giới thiệu → hình ảnh → có thể là phần còn lại.
### Quy trình viết
`
Paper Writing Checklist:
- [ ] Step 1: Define the one-sentence contribution
- [ ] Step 2: Draft Figure 1 (core idea or most compelling result)
- [ ] Step 3: Draft abstract (5-sentence formula)
- [ ] Step 4: Draft introduction (1-1.5 pages max)
- [ ] Step 5: Draft methods
- [ ] Step 6: Draft experiments & results
- [ ] Step 7: Draft related work
- [ ] Step 8: Draft conclusion & discussion
- [ ] Step 9: Draft limitations (REQUIRED by all venues)
- [ ] Step 10: Plan appendix (proofs, extra experiments, details)
- [ ] Step 11: Complete paper checklist
- [ ] Step 12: Final review
`
### Mẫu sàng lọc hai lần
Khi soạn thảo với tác nhân AI, hãy sử dụng phương pháp **hai bước** (đã được chứng minh hiệu quả trong quy trình Nhà khoa học AI của SakanaAI):
**Đạt 1 — Viết + tinh chỉnh ngay cho mỗi phần:**
Đối với mỗi phần, hãy viết một bản nháp hoàn chỉnh, sau đó chỉnh sửa ngay cho phù hợp với ngữ cảnh tương tự. Điều này nắm bắt được các vấn đề cục bộ (sự rõ ràng, dòng chảy, tính đầy đủ) trong khi phần này còn mới.
**Đạt 2 — Tinh chỉnh toàn cục với bối cảnh toàn bài:**
Sau khi tất cả các phần được soạn thảo, hãy xem lại từng phần với nhận thức về toàn bộ bài viết. Điều này nắm bắt được các vấn đề xuyên suốt: sự dư thừa, thuật ngữ không nhất quán, dòng tường thuật và những khoảng trống trong đó một phần hứa hẹn điều gì đó mà phần khác không mang lại.
`
Second-pass refinement prompt (per section):
"Review the [SECTION] in the context of the complete paper.
- Does it fit with the rest of the paper? Are there redundancies with other sections?
- Is terminology consistent with Introduction and Methods?
- Can anything be cut without weakening the message?
- Does the narrative flow from the previous section and into the next?
Make minimal, targeted edits. Do not rewrite from scratch."
`
### Danh sách kiểm tra lỗi LaTeX
Thêm danh sách kiểm tra này vào mỗi lời nhắc sàng lọc. Đây là những lỗi phổ biến nhất khi LLM viết LaTeX:
`
LaTeX Quality Checklist (verify after every edit):
- [ ] No unenclosed math symbols ($ signs balanced)
- [ ] Only reference figures/tables that exist (\ref matches \label)
- [ ] No fabricated citations (\cite matches entries in .bib)
- [ ] Every \begin\{env} has matching \end\{env} (especially figure, table, algorithm)
- [ ] No HTML contamination (</end\{figure}> instead of \end\{figure})
- [ ] No unescaped underscores outside math mode (use \_ in text)
- [ ] No duplicate \label definitions
- [ ] No duplicate section headers
- [ ] Numbers in text match actual experimental results
- [ ] All figures have captions and labels
- [ ] No overly long lines that cause overfull hbox warnings
`
### Bước 5.0: Tiêu đề
Tiêu đề là yếu tố được đọc nhiều nhất của bài báo. Nó xác định xem có ai nhấp qua phần tóm tắt hay không.
**Tiêu đề hay**:
- Nêu rõ sự đóng góp hoặc phát hiện: "Autoreason: Khi việc sàng lọc LLM lặp lại hoạt động và tại sao nó thất bại"
- Nêu bật một kết quả đáng ngạc nhiên: "Mở rộng mô hình ngôn ngữ bị ràng buộc dữ liệu" (ngụ ý rằng bạn có thể)
- Đặt tên cho phương thức + công dụng của nó: "DPO: Direct Preference Optimization of Language Models"`**Tiêu đề xấu**:
- Quá chung chung: "Phương pháp tiếp cận để cải thiện kết quả đầu ra của mô hình ngôn ngữ"
- Quá dài: bất cứ thứ gì trên ~15 từ
- Chỉ dành cho biệt ngữ: "Sự hội tụ tiệm cận của việc sàng lọc chính sách ngẫu nhiên lặp đi lặp lại" (cái này dành cho ai?)
**Quy tắc**:
- Bao gồm tên phương thức của bạn nếu có (để có thể trích dẫn)
- Bao gồm 1-2 từ khóa người đánh giá sẽ tìm kiếm
- Tránh dùng dấu hai chấm trừ khi cả hai nửa đều mang nghĩa
- Kiểm tra: liệu người đánh giá có biết tên miền và đóng góp chỉ từ tiêu đề không?
### Bước 5.1: Tóm tắt (Công thức 5 câu)
Từ Sebastian Farquhar (DeepMind):
`
1. What you achieved: "We introduce...", "We prove...", "We demonstrate..."
2. Why this is hard and important
3. How you do it (with specialist keywords for discoverability)
4. What evidence you have
5. Your most remarkable number/result
`
``**Xóa** những phần mở đầu chung chung như "Các mô hình ngôn ngữ lớn đã đạt được thành công đáng kể..."
### Bước 5.2: Hình 1
Hình 1 là thứ thứ hai mà hầu hết độc giả nhìn vào (sau phần tóm tắt). Soạn thảo trước khi viết phần giới thiệu - nó buộc bạn phải làm rõ ý tưởng cốt lõi.
| Hình 1 Loại | Khi nào nên sử dụng | Ví dụ |
|--------------|-----------------|----------|
| **Sơ đồ phương pháp** | Kiến trúc hoặc đường ống mới | Lưu đồ TikZ hiển thị hệ thống của bạn |
| **Thông báo kết quả** | Một kết quả thuyết phục kể toàn bộ câu chuyện | Biểu đồ thanh: "Của chúng tôi so với đường cơ sở" với khoảng cách rõ ràng |
| **Minh họa vấn đề** | Vấn đề không trực quan | Trước/sau hiển thị chế độ lỗi bạn sửa |
| **Sơ đồ khái niệm** | Đóng góp trừu tượng cần có nền tảng trực quan | Ma trận 2x2 của thuộc tính phương thức |
**Quy tắc**: Hình 1 phải dễ hiểu mà không cần đọc bất kỳ văn bản nào. Chỉ chú thích thôi cũng đã truyền đạt được ý tưởng cốt lõi. Sử dụng màu sắc có mục đích - không chỉ để trang trí.
### Bước 5.3: Giới thiệu (tối đa 1-1,5 trang)
Phải bao gồm:
- Trình bày vấn đề rõ ràng
- Tổng quan về cách tiếp cận ngắn gọn
- Danh sách đóng góp 2-4 dấu đầu dòng (mỗi dòng tối đa 1-2 dòng ở định dạng hai cột)
- Phương pháp nên bắt đầu từ trang 2-3
### Bước 5.4: Phương thức
Cho phép triển khai lại:
- Phác thảo khái niệm hoặc mã giả
- Tất cả các siêu tham số được liệt kê
- Chi tiết kiến trúc đủ để tái tạo
- Trình bày quyết định thiết kế cuối cùng; sự cắt bỏ đi vào thí nghiệm### Bước 5.5: Thử nghiệm & Kết quả
Đối với mỗi thí nghiệm, hãy nêu rõ:
- **Tuyên bố nào nó hỗ trợ**
- Cách nó kết nối với đóng góp chính
- Điều cần quan sát: “đường màu xanh biểu thị X, biểu thị Y”
Yêu cầu:
- Thanh lỗi với phương pháp luận (lỗi std dev vs std)
- Phạm vi tìm kiếm siêu tham số
- Cơ sở hạ tầng điện toán (loại GPU, tổng số giờ)
- Phương pháp gieo hạt
### Bước 5.6: Công việc liên quan
Tổ chức có phương pháp, không phải từng tờ giấy. Trích dẫn một cách hào phóng - những người đánh giá có thể là tác giả của các bài báo có liên quan.
### Bước 5.7: Hạn chế (BẮT BUỘC)
Tất cả các hội nghị lớn đều yêu cầu điều này. Sự trung thực giúp:
- Người phản biện được hướng dẫn không xử phạt việc thừa nhận giới hạn trung thực
- Trước những lời chỉ trích bằng cách xác định điểm yếu trước
- Giải thích tại sao những hạn chế không làm suy yếu những tuyên bố cốt lõi
### Bước 5.8: Kết luận & Thảo luận`**Kết luận** (bắt buộc, 0,5-1 trang):
- Trình bày lại phần đóng góp trong một câu (cách diễn đạt khác với phần tóm tắt)
- Tóm tắt những phát hiện chính (2-3 câu, không liệt kê)
- Ý nghĩa: điều này có ý nghĩa gì đối với lĩnh vực này?
- Công việc trong tương lai: 2-3 bước tiếp theo cụ thể (không mơ hồ “chúng ta để X cho công việc sau”)
**Thảo luận** (tùy chọn, đôi khi kết hợp với kết luận):
- Ý nghĩa rộng hơn ngoài kết quả ngay lập tức
- Kết nối với các trường con khác
- Đánh giá trung thực khi phương pháp có hiệu quả và không hiệu quả
- Cân nhắc triển khai thực tế`**KHÔNG** giới thiệu kết quả hoặc tuyên bố mới trong phần kết luận.
### Bước 5.9: Phụ lục Chiến lược
Các phụ lục là không giới hạn ở tất cả các địa điểm chính và rất cần thiết cho khả năng tái tạo. Cấu trúc:
| Phần Phụ lục | Ở Đây Có Gì |
|-----------------|---------------|
| **Bằng chứng & dẫn xuất** | Bằng chứng đầy đủ quá dài cho văn bản chính. Nội dung chính có thể phát biểu các định lý kèm theo “chứng minh ở Phụ lục A”. |
| **Thử nghiệm bổ sung** | Cắt bỏ, đường cong chia tỷ lệ, phân tích trên mỗi tập dữ liệu, độ nhạy siêu tham số |
| **Chi tiết triển khai** | Bảng siêu tham số đầy đủ, chi tiết đào tạo, thông số phần cứng, hạt giống ngẫu nhiên |
| **Tài liệu về tập dữ liệu** | Quy trình thu thập dữ liệu, hướng dẫn chú thích, cấp phép, tiền xử lý |
| **Lời nhắc & Mẫu** | Lời nhắc chính xác được sử dụng (đối với các phương pháp dựa trên LLM), mẫu đánh giá |
| **Đánh giá con người** | Ảnh chụp màn hình giao diện chú thích, hướng dẫn dành cho người chú thích, chi tiết IRB |
| **Số liệu bổ sung** | Phân tích theo từng nhiệm vụ, trực quan hóa quỹ đạo, ví dụ về trường hợp thất bại |
**Quy tắc**:
- Bài viết chính phải khép kín, người phản biện không cần đọc phần phụ lục
- Không bao giờ chỉ đưa bằng chứng quan trọng vào phần phụ lục
- Tham khảo chéo: “Kết quả đầy đủ tại Bảng 5 (Phụ lục B)” chứ không chỉ “xem phụ lục”
- Sử dụng lệnh
\appendix
, sau đó
\section\{A: Proofs}
, v.v.
### Quản lý ngân sách trang
Khi vượt quá giới hạn trang:
| Chiến lược cắt giảm | Lưu | Rủi ro |
|----------||-------|------|
| Chuyển bằng chứng sang phụ lục | 0,5-2 trang | Thực hành tiêu chuẩn thấp |
| Cô đọng công việc liên quan | 0,5-1 trang | Trung bình — có thể bỏ lỡ các trích dẫn chính |
| Kết hợp các bảng với các cấu hình con | 0,25-0,5 trang | Thấp — thường cải thiện khả năng đọc |
| Sử dụng
\vspace\{-Xpt}
` một cách tiết kiệm | trang 0,1-0,3 | Thấp nếu tinh tế, cao nếu rõ ràng |
| Loại bỏ các ví dụ định tính | 0,5-1 trang | Trung bình — người đánh giá thích các ví dụ |
| Giảm kích thước hình | 0,25-0,5 trang | Cao - số liệu phải vẫn có thể đọc được |
**KHÔNG**: giảm kích thước phông chữ, thay đổi lề, xóa các phần bắt buộc (hạn chế, tác động rộng hơn) hoặc sử dụng
\small
/
\footnotesize
` cho văn bản chính.
### Bước 5.10: Tuyên bố về đạo đức và tác động rộng hơn
Hầu hết các địa điểm hiện nay đều yêu cầu hoặc khuyến khích mạnh mẽ một tuyên bố về đạo đức/tác động rộng hơn. Đây không phải là bản soạn sẵn — người đánh giá đọc nó và có thể gắn cờ những mối lo ngại về đạo đức dẫn đến việc từ chối bàn.
**Nội dung cần bao gồm:**
| Thành phần | Nội dung | Được yêu cầu bởi |
|----------||----------|-------------|
| **Tác động xã hội tích cực** | Công việc của bạn mang lại lợi ích cho xã hội như thế nào | Thần kinhIPS, ICML |
| **Tác động tiêu cực tiềm tàng** | Rủi ro sử dụng sai, mối lo ngại về việc sử dụng kép, các dạng lỗi | Thần kinhIPS, ICML |
| **Công bằng và thiên vị** | Phương pháp/dữ liệu của bạn có những sai lệch đã biết không? | Tất cả các địa điểm (ngầm) |
| **Tác động môi trường** | Tính toán lượng khí thải carbon cho đào tạo quy mô lớn | ICML, NeurIPS ngày càng tăng |
| **Quyền riêng tư** | Công việc của bạn có sử dụng hoặc cho phép xử lý dữ liệu cá nhân không? | ACL, Thần kinh |
| **Tiết lộ LLM** | AI có được sử dụng trong văn bản hoặc thí nghiệm không? | ICLR (bắt buộc), ACL |
**Viết bài phát biểu:**
`latex
\section*\{Broader Impact Statement}
% NeurIPS/ICML: after conclusion, does not count toward page limit`% 1. Positive applications (1-2 sentences)
This work enables [specific application] which may benefit [specific group].`% 2. Risks and mitigations (1-3 sentences, be specific)
[Method/model] could potentially be misused for [specific risk]. We mitigate
this by [specific mitigation, e.g., releasing only model weights above size X,
including safety filters, documenting failure modes].`% 3. Limitations of impact claims (1 sentence)
Our evaluation is limited to [specific domain]; broader deployment would
require [specific additional work].
`
`**Các lỗi thường gặp:**
- Viết "chúng tôi thấy trước không có tác động tiêu cực" (gần như không bao giờ đúng - người đánh giá không tin vào điều này)
- Mơ hồ: “điều này có thể bị lạm dụng” mà không chỉ rõ cách thức
- Bỏ qua chi phí tính toán cho công việc quy mô lớn
- Quên tiết lộ việc sử dụng LLM tại các địa điểm yêu cầu`**Tính lượng khí thải carbon** (đối với các bài viết nặng về đào tạo):
`
``` python
# Estimate using ML CO2 Impact tool methodology
gpu_hours = 1000 # total GPU hours
gpu_tdp_watts = 400 # e.g., A100 = 400W
pue = 1.1 # Power Usage Effectiveness (data center overhead)
carbon_intensity = 0.429 # kg CO2/kWh (US average; varies by region)
energy_kwh = (gpu_hours * gpu_tdp_watts * pue) / 1000
carbon_kg = energy_kwh * carbon_intensity
print(f"Energy: \{energy_kwh:.0f} kWh, Carbon: \{carbon_kg:.0f} kg CO2eq")
`
### Bước 5.11: Bảng dữ liệu & Thẻ mẫu (Nếu có)
Nếu bài viết của bạn giới thiệu một **tập dữ liệu mới** hoặc **phát hành một mô hình**, hãy bao gồm tài liệu có cấu trúc. Người đánh giá ngày càng mong đợi điều này và theo dõi Bộ dữ liệu & Điểm chuẩn của NeurIPS yêu cầu điều đó.
**Bảng dữ liệu cho Bộ dữ liệu** (Gebru và cộng sự, 2021) - bao gồm trong phụ lục:
`
Dataset Documentation (Appendix):
- Motivation: Why was this dataset created? What task does it support?
- Composition: What are the instances? How many? What data types?
- Collection: How was data collected? What was the source?
- Preprocessing: What cleaning/filtering was applied?
- Distribution: How is the dataset distributed? Under what license?
- Maintenance: Who maintains it? How to report issues?
- Ethical considerations: Contains personal data? Consent obtained?
Potential for harm? Known biases?
`
``**Thẻ mẫu** (Mitchell và cộng sự, 2019) — có trong phụ lục dành cho các bản phát hành mô hình:
`
Model Card (Appendix):
- Model details: Architecture, training data, training procedure
- Intended use: Primary use cases, out-of-scope uses
- Metrics: Evaluation metrics and results on benchmarks
- Ethical considerations: Known biases, fairness evaluations
- Limitations: Known failure modes, domains where model underperforms
`
### Phong cách viết`**Sự rõ ràng ở cấp độ câu (7 nguyên tắc của Gopen & Swan):**
| Nguyên tắc | Quy tắc |
|----------||------|
| Sự gần gũi giữa chủ ngữ và động từ | Giữ chủ ngữ và động từ gần nhau |
| Vị trí căng thẳng | Nhấn mạnh ở cuối câu |
| Vị trí chủ đề | Đặt ngữ cảnh lên hàng đầu, thông tin mới sau |
| Cũ trước mới | Thông tin quen thuộc → thông tin lạ |
| Một đơn vị, một chức năng | Mỗi đoạn văn nêu một điểm |
| Hành động trong động từ | Sử dụng động từ, không phải danh nghĩa |
| Bối cảnh trước mới | Chuẩn bị sân khấu trước khi thuyết trình |
**Lựa chọn từ (Lipton, Steinhardt):**
- Hãy cụ thể: “chính xác” chứ không phải “hiệu suất”
- Loại bỏ phòng ngừa rủi ro: bỏ “có thể” trừ khi thực sự không chắc chắn
- Thuật ngữ nhất quán xuyên suốt
- Tránh tăng dần từ vựng: “phát triển” chứ không phải “kết hợp”`**Hướng dẫn viết đầy đủ kèm ví dụ**: Xem [references/writing-guide.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/skills/research/research-paper-writing/references/writing-guide.md)
### Sử dụng mẫu LaTeX`**Luôn sao chép toàn bộ thư mục mẫu trước rồi viết vào đó.**
`
Template Setup Checklist:
- [ ] Step 1: Copy entire template directory to new project
- [ ] Step 2: Verify template compiles as-is (before any changes)
- [ ] Step 3: Read the template's example content to understand structure
- [ ] Step 4: Replace example content section by section
- [ ] Step 5: Use template macros (check preamble for \newcommand definitions)
- [ ] Step 6: Clean up template artifacts only at the end
`
``**Bước 1: Sao chép toàn bộ mẫu**
``` bash
cp -r templates/neurips2025/ ~/papers/my-paper/
cd ~/papers/my-paper/
ls -la # Should see: main.tex, neurips.sty, Makefile, etc.
`
``Sao chép TOÀN BỘ thư mục, không chỉ tệp .tex. Mẫu bao gồm các tệp kiểu (.sty), kiểu thư mục (.bst), nội dung ví dụ và Makefiles.
**Bước 2: Xác minh việc biên dịch mẫu trước**
Trước khi thực hiện BẤT KỲ thay đổi nào:
`
`bash
latexmk -pdf main.tex
# Or manual: pdflatex main.tex && bibtex main && pdflatex main.tex && pdflatex main.tex
`
``Nếu mẫu chưa sửa đổi không biên dịch được, hãy sửa mẫu đó trước (thường thiếu gói TeX — cài đặt qua
`tlmgr install <package>
).
**Bước 3: Giữ nội dung mẫu làm tài liệu tham khảo**
Đừng xóa ngay nội dung ví dụ. Nhận xét nó và sử dụng làm tài liệu tham khảo định dạng:
`
`latex
% Template example (keep for reference):
% \begin\{figure}[t]
% \centering
% \includegraphics[width=0.8\linewidth]\{example-image}
% \caption\{Template shows caption style}
% \end\{figure}`% Your actual figure:
\begin\{figure}[t]
\centering
\includegraphics[width=0.8\linewidth]\{your-figure.pdf}
\caption\{Your caption following the same style.}
\end\{figure}
`
``**Bước 4: Thay thế từng phần nội dung**
Thực hiện một cách có hệ thống: tựa đề/tác giả → tóm tắt → giới thiệu → phương pháp → thí nghiệm → công việc liên quan → kết luận → tài liệu tham khảo → phụ lục. Biên dịch sau mỗi phần.
**Bước 5: Sử dụng Macro mẫu**
`latex
\newcommand\{\method}\{YourMethodName} % Consistent method naming
\newcommand\{\eg}\{e.g.,\xspace} % Proper abbreviations
\newcommand\{\ie}\{i.e.,\xspace}
`
### Cạm bẫy mẫu
| Cạm bẫy | Vấn đề | Giải pháp |
|----------|----------|----------|
| Chỉ sao chép tệp
.tex
` | Thiếu
.sty
, sẽ không biên dịch | Sao chép toàn bộ thư mục |
| Sửa đổi tệp
.sty
` | Phá vỡ định dạng hội nghị | Không bao giờ chỉnh sửa tập tin kiểu |
| Thêm gói ngẫu nhiên | Xung đột, phá vỡ mẫu | Chỉ thêm nếu cần thiết |
| Xóa nội dung mẫu sớm | Mất tham chiếu định dạng | Giữ làm bình luận cho đến khi hoàn thành |
| Không biên soạn thường xuyên | Lỗi tích lũy | Biên dịch sau mỗi phần |
| Raster PNG cho số liệu | Giấy mờ | Luôn sử dụng PDF vector qua
`savefig('fig.pdf')
` |
### Tham khảo mẫu nhanh
| Hội nghị | Tệp chính | Tệp kiểu | Giới hạn trang |
|----------||-------------|-------------|----------||
| NeurIPS 2025 |
main.tex
` |
`neurips.sty
` | 9 trang |
| ICML 2026 |
example_paper.tex
` |
`icml2026.sty
` | 8 trang |
| ICLR 2026 |
iclr2026_conference.tex
` |
`iclr2026_conference.sty
` | 9 trang |
| ACL 2025 |
acl_latex.tex
` |
`acl.sty
` | 8 trang (dài) |
| AAAI 2026 |
aaai2026-unified-template.tex
` |
`aaai2026.sty
` | 7 trang |
| COLM 2025 |
colm2025_conference.tex
` |
`colm2025_conference.sty
` | 9 trang |
**Universal**: Double-blind, không tính tài liệu tham khảo, không giới hạn phụ lục, bắt buộc phải có LaTeX.
Các mẫu trong thư mục
`templates/
. Xem [templates/README.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/skills/research/research-paper-writing/templates/README.md) để biết thiết lập biên dịch (Mã VS, CLI, Overleaf, các IDE khác).
### Bảng và hình`**Bảng** — sử dụng
`booktabs
` để định dạng chuyên nghiệp:
`latex
\usepackage\{booktabs}
\begin\{tabular}\{lcc}
\toprule
Method & Accuracy $\uparrow$ & Latency $\downarrow$ \\
\midrule
Baseline & 85.2 & 45ms \\
\textbf\{Ours} & \textbf\\{92.1} & 38ms \\
\bottomrule
\end\{tabular}
`
``Quy tắc:
- In đậm giá trị tốt nhất cho mỗi số liệu
- Bao gồm các ký hiệu chỉ hướng ($\uparrow$ cao hơn tốt hơn, $\downarrow$ thấp hơn tốt hơn)
- Căn phải các cột số
- Độ chính xác thập phân nhất quán**Số liệu**:
- **Đồ họa vector** (PDF, EPS) cho tất cả các ô và sơ đồ —
`plt.savefig('fig.pdf')
- **Raster** (PNG 600 dpi) chỉ dành cho ảnh
- **Bảng màu an toàn cho người mù màu** (Okabe-Ito hoặc Paul Tol)
- Xác minh **khả năng đọc thang độ xám** (8% nam giới bị thiếu thị lực màu)
- **Không có tiêu đề bên trong hình** — chú thích phục vụ chức năng này
- **Chú thích khép kín** — người đọc sẽ hiểu nếu không cần nội dung chính
### Gửi lại hội nghị
Để chuyển đổi giữa các địa điểm, hãy xem Giai đoạn 7 (Chuẩn bị gửi) — nó bao gồm toàn bộ quy trình chuyển đổi, bảng thay đổi trang và hướng dẫn sau từ chối.
### Lời mở đầu LaTeX chuyên nghiệp
Thêm các gói này vào bất kỳ loại giấy nào để có chất lượng chuyên nghiệp. Chúng tương thích với tất cả các tệp kiểu hội nghị lớn:
`latex
% --- Professional Packages (add after conference style file) ---
% Typography
\usepackage\{microtype} % Microtypographic improvements (protrusion, expansion)
% Makes text noticeably more polished — always include`% Tables
\usepackage\{booktabs} % Professional table rules (\toprule, \midrule, \bottomrule)
\usepackage\{siunitx} % Consistent number formatting, decimal alignment
% Usage: \num\\{12345} → 12,345; \SI\\{3.5}\{GHz} → 3.5 GHz
% Table alignment: S column type for decimal-aligned numbers`% Figures
\usepackage\{graphicx} % Include graphics (\includegraphics)
\usepackage\{subcaption} % Subfigures with (a), (b), (c) labels
% Usage: \begin\{subfigure}\\{0.48\textwidth} ... \end\{subfigure}`% Diagrams and Algorithms
\usepackage\{tikz} % Programmable vector diagrams
\usetikzlibrary\{arrows.meta, positioning, shapes.geometric, calc, fit, backgrounds}
\usepackage[ruled,vlined]\{algorithm2e} % Professional pseudocode
% Alternative: \usepackage\{algorithmicx} if template bundles it`% Cross-references
\usepackage\{cleveref} % Smart references: \cref\{fig:x} → "Figure 1"
% MUST be loaded AFTER hyperref
% Handles: figures, tables, sections, equations, algorithms`% Math (usually included by conference .sty, but verify)
\usepackage\{amsmath,amssymb} % AMS math environments and symbols
\usepackage\{mathtools} % Extends amsmath (dcases, coloneqq, etc.)`% Colors (for figures and diagrams)
\usepackage\{xcolor} % Color management
% Okabe-Ito colorblind-safe palette:
\definecolor\{okblue}\{HTML}\\{0072B2}
\definecolor\{okorange}\{HTML}\{E69F00}
\definecolor\{okgreen}\{HTML}\\{009E73}
\definecolor\{okred}\{HTML}\{D55E00}
\definecolor\{okpurple}\{HTML}\{CC79A7}
\definecolor\{okcyan}\{HTML}\\{56B4E9}
\definecolor\{okyellow}\{HTML}\{F0E442}
`
``**Ghi chú:**
-
`microtype
` là gói có tác động cao nhất đến chất lượng hình ảnh. Nó điều chỉnh khoảng cách ký tự ở mức pixel phụ. Luôn luôn bao gồm nó.
-
`siunitx
` xử lý căn chỉnh thập phân trong bảng thông qua loại cột
`S
` — loại bỏ khoảng cách thủ công.
-
`cleveref
` phải được tải **sau**
`hyperref
. Hầu hết các tệp .sty của hội nghị đều tải hyperref, vì vậy hãy đặt smartef ở cuối.
- Kiểm tra xem mẫu hội nghị đã tải bất kỳ mẫu nào trong số này chưa (đặc biệt là
`algorithm
,
`amsmath
,
`graphicx
). Đừng tải gấp đôi.
### Căn chỉnh bảng siunitx``siunitx
` làm cho các bảng nhiều số trở nên dễ đọc hơn đáng kể:
`latex
\begin\{tabular}\{l S[table-format=2.1] S[table-format=2.1] S[table-format=2.1]}
\toprule
Method & \{Accuracy $\uparrow$} & \{F1 $\uparrow$} & \{Latency (ms) $\downarrow$} \\
\midrule
Baseline & 85.2 & 83.7 & 45.3 \\
Ablation (no X) & 87.1 & 85.4 & 42.1 \\
\textbf\{Ours} & \textbf\\{92.1} & \textbf\\{90.8} & \textbf\\{38.7} \\
\bottomrule
\end\{tabular}
`
``Loại cột
`S
` tự động căn chỉnh theo dấu thập phân. Các tiêu đề trong
\{}
` không được căn chỉnh.
### Cấu hình phụ
Mẫu chuẩn cho các hình cạnh nhau:
`latex
\begin\{figure}[t]
\centering
\begin\{subfigure}[b]\\{0.48\textwidth}
\centering
\includegraphics[width=\textwidth]\{fig_results_a.pdf}
\caption\{Results on Dataset A.}
\label\{fig:results-a}
\end\{subfigure}
\hfill
\begin\{subfigure}[b]\\{0.48\textwidth}
\centering
\includegraphics[width=\textwidth]\{fig_results_b.pdf}
\caption\{Results on Dataset B.}
\label\{fig:results-b}
\end\{subfigure}
\caption\{Comparison of our method across two datasets. (a) shows the scaling
behavior and (b) shows the ablation results. Both use 5 random seeds.}
\label\{fig:results}
\end\{figure}
`
``Sử dụng
\cref\{fig:results}
` → "Hình 1",
\cref\{fig:results-a}
` → "Hình 1a".
### Mã giả với thuật toán2e
`latex
\begin\{algorithm}[t]
\caption\{Iterative Refinement with Judge Panel}
\label\{alg:method}
\KwIn\{Task $T$, model $M$, judges $J_1 \ldots J_n$, convergence threshold $k$}
\KwOut\{Final output $A^*$}
$A \gets M(T)$ \tcp*\{Initial generation}
$\text\{streak} \gets 0$\;
\While\{$\text\{streak} < k$}{
$C \gets \text\{Critic}(A, T)$ \tcp*\{Identify weaknesses}
$B \gets M(T, C)$ \tcp*\{Revised version addressing critique}
$AB \gets \text\{Synthesize}(A, B)$ \tcp*\{Merge best elements}
\ForEach\{judge $J_i$}{
$\text\{rank}_i \gets J_i(\text\{shuffle}(A, B, AB))$ \tcp*\{Blind ranking}
}
$\text\{winner} \gets \text\{BordaCount}(\text\{ranks})$\;
\eIf\{$\text\{winner} = A$}{
$\text\{streak} \gets \text\{streak} + 1$\;
}{
$A \gets \text\{winner}$; $\text\{streak} \gets 0$\;
}
}
\Return\{$A$}\;
\end\{algorithm}
`
### Mẫu sơ đồ TikZ
TikZ là tiêu chuẩn cho sơ đồ phương pháp trong các bài viết ML. Các mẫu phổ biến:
**Sơ đồ đường ống/dòng chảy** (phổ biến nhất trong các tài liệu ML):
`latex
\begin\{figure}[t]
\centering
\begin\{tikzpicture}[
node distance=1.8cm,
box/.style=\{rectangle, draw, rounded corners, minimum height=1cm,
minimum width=2cm, align=center, font=\small},
arrow/.style=\{-\{Stealth[length=3mm]}, thick},
]
\node[box, fill=okcyan!20] (input) \{Input\\$x$};
\node[box, fill=okblue!20, right of=input] (encoder) \{Encoder\\$f_\theta$};
\node[box, fill=okgreen!20, right of=encoder] (latent) \{Latent\\$z$};
\node[box, fill=okorange!20, right of=latent] (decoder) \{Decoder\\$g_\phi$};
\node[box, fill=okred!20, right of=decoder] (output) \{Output\\$\hat\{x}$};`\draw[arrow] (input) -- (encoder);
\draw[arrow] (encoder) -- (latent);
\draw[arrow] (latent) -- (decoder);
\draw[arrow] (decoder) -- (output);
\end\{tikzpicture}
\caption\{Architecture overview. The encoder maps input $x$ to latent
representation $z$, which the decoder reconstructs.}
\label\{fig:architecture}
\end\{figure}
`
``**Sơ đồ so sánh/ma trận** (để hiển thị các biến thể của phương pháp):
`latex
\begin\{tikzpicture}[
cell/.style=\{rectangle, draw, minimum width=2.5cm, minimum height=1cm,
align=center, font=\small},
header/.style=\{cell, fill=gray!20, font=\small\bfseries},
]
% Headers
\node[header] at (0, 0) \{Method};
\node[header] at (3, 0) \{Converges?};
\node[header] at (6, 0) \{Quality?};
% Rows
\node[cell] at (0, -1) \{Single Pass};
\node[cell, fill=okgreen!15] at (3, -1) \{N/A};
\node[cell, fill=okorange!15] at (6, -1) \{Baseline};
\node[cell] at (0, -2) \{Critique+Revise};
\node[cell, fill=okred!15] at (3, -2) \{No};
\node[cell, fill=okred!15] at (6, -2) \{Degrades};
\node[cell] at (0, -3) \{Ours};
\node[cell, fill=okgreen!15] at (3, -3) \{Yes ($k$=2)};
\node[cell, fill=okgreen!15] at (6, -3) \{Improves};
\end\{tikzpicture}
`
``**Sơ đồ vòng lặp** (dành cho các phương pháp có phản hồi):
`latex
\begin\{tikzpicture}[
node distance=2cm,
box/.style=\{rectangle, draw, rounded corners, minimum height=0.8cm,
minimum width=1.8cm, align=center, font=\small},
arrow/.style=\{-\{Stealth[length=3mm]}, thick},
label/.style=\{font=\scriptsize, midway, above},
]
\node[box, fill=okblue!20] (gen) \{Generator};
\node[box, fill=okred!20, right=2.5cm of gen] (critic) \{Critic};
\node[box, fill=okgreen!20, below=1.5cm of $(gen)!0.5!(critic)$] (judge) \{Judge Panel};`\draw[arrow] (gen) -- node[label] \{output $A$} (critic);
\draw[arrow] (critic) -- node[label, right] \{critique $C$} (judge);
\draw[arrow] (judge) -| node[label, left, pos=0.3] \{winner} (gen);
\end\{tikzpicture}
`
### latexdiff để theo dõi sửa đổi
Cần thiết cho việc bác bỏ - tạo một tệp PDF được đánh dấu hiển thị các thay đổi giữa các phiên bản:
``` bash
# Install
# macOS: brew install latexdiff (or comes with TeX Live)
# Linux: sudo apt install latexdiff
# Generate diff
latexdiff paper_v1.tex paper_v2.tex > paper_diff.tex
pdflatex paper_diff.tex
# For multi-file projects (with \input\{} or \include\{})
latexdiff --flatten paper_v1.tex paper_v2.tex > paper_diff.tex
`
``Thao tác này sẽ tạo ra một tệp PDF có phần xóa bị gạch ngang màu đỏ và phần bổ sung có màu xanh lam — định dạng tiêu chuẩn dành cho phần bổ sung phản bác.
### SciencePlots cho matplotlib
Cài đặt và sử dụng cho các lô chất lượng xuất bản:
``` bash
pip install SciencePlots
`
`
`Python
import matplotlib.pyplot as plt
import scienceplots # registers styles
# Use science style (IEEE-like, clean)
with plt.style.context(['science', 'no-latex']):
fig, ax = plt.subplots(figsize=(3.5, 2.5)) # Single-column width
ax.plot(x, y, label='Ours', color='#0072B2')
ax.plot(x, y2, label='Baseline', color='#D55E00', linestyle='--')
ax.set_xlabel('Training Steps')
ax.set_ylabel('Accuracy')
ax.legend()
fig.savefig('paper/fig_results.pdf', bbox_inches='tight')
# Available styles: 'science', 'ieee', 'nature', 'science+ieee'
# Add 'no-latex' if LaTeX is not installed on the machine generating plots
`
``**Kích thước hình tiêu chuẩn** (định dạng hai cột):
- Cột đơn:
`figsize=(3.5, 2.5)
- vừa với một cột
- Cột đôi:
`figsize=(7.0, 3.0)
- kéo dài cả hai cột
- Hình vuông:
`figsize=(3.5, 3.5)
- dành cho bản đồ nhiệt, ma trận nhầm lẫn
---
## Giai đoạn 6: Tự rà soát & Sửa đổi`**Mục tiêu**: Mô phỏng quá trình xem xét trước khi gửi. Nắm bắt điểm yếu sớm.
### Bước 6.1: Mô phỏng các bài đánh giá (Mẫu tập hợp)
Tạo đánh giá từ nhiều góc độ. Thông tin chi tiết quan trọng từ quy trình nghiên cứu tự động (đặc biệt là Nhà khoa học AI của SakanaAI): **đánh giá tổng hợp với người đánh giá tổng hợp tạo ra phản hồi được hiệu chỉnh nhiều hơn so với một lần đánh giá duy nhất.**`**Bước 1: Tạo N đánh giá độc lập** (N=3-5)
Sử dụng các mô hình hoặc cài đặt nhiệt độ khác nhau. Mỗi người đánh giá chỉ nhìn thấy bài báo chứ không nhìn thấy những đánh giá khác. **Mặc định là thành kiến tiêu cực** — LLM có thành kiến tích cực được ghi chép rõ ràng trong đánh giá.
`
You are an expert reviewer for [VENUE]. You are critical and thorough.
If a paper has weaknesses or you are unsure about a claim, flag it clearly
and reflect that in your scores. Do not give the benefit of the doubt.
Review this paper according to the official reviewer guidelines. Evaluate:
1. Soundness (are claims well-supported? are baselines fair and strong?)
2. Clarity (is the paper well-written? could an expert reproduce it?)
3. Significance (does this matter to the community?)
4. Originality (new insights, not just incremental combination?)
Provide your review as structured JSON:
{
"summary": "2-3 sentence summary",
"strengths": ["strength 1", "strength 2", ...],
"weaknesses": ["weakness 1 (most critical)", "weakness 2", ...],
"questions": ["question for authors 1", ...],
"missing_references": ["paper that should be cited", ...],
"soundness": 1-4,
"presentation": 1-4,
"contribution": 1-4,
"overall": 1-10,
"confidence": 1-5
}
`
``**Bước 2: Đánh giá tổng hợp (tổng hợp Chủ tịch khu vực)**
Cung cấp tất cả N đánh giá cho người đánh giá tổng hợp:
`
You are an Area Chair at [VENUE]. You have received [N] independent reviews
of a paper. Your job is to:
1. Identify consensus strengths and weaknesses across reviewers
2. Resolve disagreements by examining the paper directly
3. Produce a meta-review that represents the aggregate judgment
4. Use AVERAGED numerical scores across all reviews
Be conservative: if reviewers disagree on whether a weakness is serious,
treat it as serious until the authors address it.
Reviews:
[review_1]
[review_2]
...
`
``**Bước 3: Vòng phản xạ** (tùy chọn, 2-3 vòng)
Mỗi người đánh giá có thể tinh chỉnh đánh giá của họ sau khi xem đánh giá tổng hợp. Sử dụng trọng điểm chấm dứt sớm: nếu người đánh giá trả lời "Tôi đã hoàn tất" (không có thay đổi nào), hãy ngừng lặp lại.
**Lựa chọn mô hình để đánh giá**: Việc đánh giá được thực hiện tốt nhất với mô hình mạnh nhất hiện có, ngay cả khi bạn viết bài bằng mô hình rẻ hơn. Mô hình người đánh giá nên được chọn độc lập với mô hình viết.
**Hiệu chỉnh một vài lần chụp**: Nếu có, hãy đưa 1-2 bài đánh giá thực tế được công bố từ địa điểm mục tiêu làm ví dụ. Điều này cải thiện đáng kể hiệu chuẩn điểm số. Xem [references/reviewer-guidelines.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/skills/research/research-paper-writing/references/reviewer-guidelines.md) để biết các đánh giá ví dụ.
### Bước 6.1b: Thẻ đánh giá trực quan (VLM)
Đánh giá chỉ bằng văn bản bỏ qua toàn bộ các vấn đề: chất lượng hình ảnh, vấn đề về bố cục, tính nhất quán về mặt hình ảnh. Nếu bạn có quyền truy cập vào một mô hình có khả năng nhìn, hãy chạy **đánh giá trực quan** riêng trên bản PDF đã biên dịch:
`
You are reviewing the visual presentation of this research paper PDF.
Check for:
1. Figure quality: Are plots readable? Labels legible? Colors distinguishable?
2. Figure-caption alignment: Does each caption accurately describe its figure?
3. Layout issues: Orphaned section headers, awkward page breaks, figures far from their references
4. Table formatting: Aligned columns, consistent decimal precision, bold for best results
5. Visual consistency: Same color scheme across all figures, consistent font sizes
6. Grayscale readability: Would the figures be understandable if printed in B&W?
For each issue, specify the page number and exact location.
`
``Điều này phát hiện các vấn đề mà việc đánh giá dựa trên văn bản không thể khắc phục được: một biểu đồ có nhãn trục khó đọc, một hình được đặt cách tham chiếu đầu tiên của nó 3 trang, bảng màu không nhất quán giữa Hình 2 và Hình 5 hoặc một bảng rõ ràng rộng hơn chiều rộng cột.
### Bước 6.1c: Thẻ xác minh yêu cầu
Sau khi đánh giá mô phỏng, hãy chạy một lượt xác minh riêng. Điều này phát hiện các lỗi thực tế mà người đánh giá có thể bỏ sót:
`
Claim Verification Protocol:
1. Extract every factual claim from the paper (numbers, comparisons, trends)
2. For each claim, trace it to the specific experiment/result that supports it
3. Verify the number in the paper matches the actual result file
4. Flag any claim without a traceable source as [VERIFY]
`
``Đối với quy trình làm việc dựa trên tác nhân: ủy quyền xác minh cho **tác nhân phụ mới** chỉ nhận văn bản giấy và tệp kết quả thô. Bối cảnh mới sẽ ngăn ngừa sai lệch xác nhận — người xác minh không "nhớ" kết quả lẽ ra phải như thế nào.
### Bước 6.2: Ưu tiên phản hồi
Sau khi thu thập đánh giá, hãy phân loại:
| Ưu tiên | Hành động |
|----------|--------|
| **Nghiêm trọng** (lỗi kỹ thuật, thiếu đường cơ sở) | Phải sửa. Có thể yêu cầu thử nghiệm mới → quay lại Giai đoạn 2 |
| **Cao** (vấn đề về độ trong, thiếu sự cắt bỏ) | Nên khắc phục ở lần sửa đổi này |
| **Trung bình** (các vấn đề nhỏ về viết, thử nghiệm bổ sung) | Sửa chữa nếu thời gian cho phép |
| **Thấp** (tùy chọn phong cách, đề xuất tiếp tuyến) | Lưu ý cho công việc trong tương lai |
### Bước 6.3: Chu trình sửa đổi
Đối với mỗi vấn đề quan trọng/cao:
1. Xác định (các) đoạn cụ thể bị ảnh hưởng
2. Dự thảo cách khắc phục
3. Xác minh bản sửa lỗi không vi phạm các xác nhận quyền sở hữu khác
4. Cập nhật bài báo
5. Kiểm tra lại mối quan tâm của người đánh giá
### Bước 6.4: Viết phản bác
Khi phản hồi các đánh giá thực tế (sau khi gửi), phản bác là một kỹ năng khác biệt so với sửa đổi:
**Định dạng**: Từng điểm một. Đối với mỗi mối quan tâm của người đánh giá:
`
> R1-W1: "The paper lacks comparison with Method X."
We thank the reviewer for this suggestion. We have added a comparison with
Method X in Table 3 (revised). Our method outperforms X by 3.2pp on [metric]
(p<0.05). We note that X requires 2x our compute budget.
`
``**Quy tắc**:
- Giải quyết mọi mối lo ngại — người đánh giá sẽ thông báo nếu bạn bỏ qua một mối lo ngại
- Dẫn đầu với những phản hồi mạnh mẽ nhất
- Hãy ngắn gọn và trực tiếp — người đánh giá đọc hàng chục lời bác bỏ
- Bao gồm các kết quả mới nếu bạn chạy thử nghiệm trong thời gian phản bác
- Không bao giờ tỏ ra phòng thủ hay bác bỏ, thậm chí với những lời chỉ trích yếu ớt
- Sử dụng
`latexdiff
` để tạo tệp PDF được đánh dấu hiển thị các thay đổi (xem phần Công cụ LaTeX chuyên nghiệp)
- Cảm ơn người đánh giá về những phản hồi cụ thể, hữu ích (không khen ngợi chung chung)
**Điều KHÔNG nên làm**: "Chúng tôi không đồng ý một cách tôn trọng" mà không có bằng chứng. "Điều này nằm ngoài phạm vi" mà không có lời giải thích. Bỏ qua điểm yếu bằng cách chỉ phản ứng với điểm mạnh.
### Bước 6.5: Theo dõi quá trình tiến triển của giấy
Lưu ảnh chụp nhanh ở các mốc quan trọng:
`
paper/
paper.tex # Current working version
paper_v1_first_draft.tex # First complete draft
paper_v2_post_review.tex # After simulated review
paper_v3_pre_submission.tex # Final before submission
paper_v4_camera_ready.tex # Post-acceptance final
`
---
## Giai đoạn 7: Chuẩn bị nộp hồ sơ`**Mục tiêu**: Kiểm tra lần cuối, định dạng và gửi.
### Bước 7.1: Danh sách kiểm tra hội nghị
Mỗi địa điểm đều có danh sách kiểm tra bắt buộc. Hoàn thành chúng một cách cẩn thận - danh sách kiểm tra không đầy đủ có thể dẫn đến việc bị từ chối.
Xem [references/checklists.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/skills/research/research-paper-writing/references/checklists.md) để biết:
- Danh sách kiểm tra giấy 16 mục của NeurIPS
- Tác động rộng hơn của ICML + khả năng tái tạo
- Chính sách tiết lộ của ICLR LLM
- Phần giới hạn bắt buộc của ACL
- Danh sách kiểm tra trước khi nộp phổ quát
### Bước 7.2: Danh sách kiểm tra ẩn danh
Đánh giá mù đôi có nghĩa là người đánh giá không thể biết ai đã viết bài báo. Kiểm tra TẤT CẢ những điều này:
`
Anonymization Checklist:
- [ ] No author names or affiliations anywhere in the PDF
- [ ] No acknowledgments section (add after acceptance)
- [ ] Self-citations written in third person: "Smith et al. [1] showed..." not "We previously showed [1]..."
- [ ] No GitHub/GitLab URLs pointing to your personal repos
- [ ] Use Anonymous GitHub (https://anonymous.4open.science/) for code links
- [ ] No institutional logos or identifiers in figures
- [ ] No file metadata containing author names (check PDF properties)
- [ ] No "our previous work" or "in our earlier paper" phrasing
- [ ] Dataset names don't reveal institution (rename if needed)
- [ ] Supplementary materials don't contain identifying information
`
``**Các lỗi thường gặp**: Thông báo cam kết Git hiển thị trong mã bổ sung, số liệu có hình chìm mờ từ các công cụ của tổ chức, xác nhận còn lại từ bản nháp trước, bản in trước arXiv được đăng trước giai đoạn ẩn danh.
### Bước 7.3: Xác minh định dạng
`
Pre-Submission Format Check:
- [ ] Page limit respected (excluding references and appendix)
- [ ] All figures are vector (PDF) or high-res raster (600 DPI PNG)
- [ ] All figures readable in grayscale
- [ ] All tables use booktabs
- [ ] References compile correctly (no "?" in citations)
- [ ] No overfull hboxes in critical areas
- [ ] Appendix clearly labeled and separated
- [ ] Required sections present (limitations, broader impact, etc.)
`
### Bước 7.4: Xác thực trước khi biên dịch
Chạy các bước kiểm tra tự động này **trước khi** thử
`pdflatex
. Việc bắt lỗi ở đây nhanh hơn việc gỡ lỗi đầu ra của trình biên dịch.
``` bash
# 1. Lint with chktex (catches common LaTeX mistakes)
# Suppress noisy warnings: -n2 (sentence end), -n24 (parens), -n13 (intersentence), -n1 (command terminated)
chktex main.tex -q -n2 -n24 -n13 -n1
# 2. Verify all citations exist in .bib
# Extract \cite\{...} from .tex, check each against .bib
Python3 -c "
import re
tex = open('main.tex').read()
bib = open('references.bib').read()
cites = set(re.findall(r'\\\\cite[tp]?\{([^}]+)}', tex))
for cite_group in cites:
for cite in cite_group.split(','):
cite = cite.strip()
if cite and cite not in bib:
print(f'WARNING: \\\\cite\{\{\{cite}}} not found in references.bib')
"
# 3. Verify all referenced figures exist on disk
Python3 -c "
import re, os
tex = open('main.tex').read()
figs = re.findall(r'\\\\includegraphics(?:\[.*?\])?\{([^}]+)}', tex)
for fig in figs:
if not os.path.exists(fig):
print(f'WARNING: Figure file not found: \{fig}')
"
# 4. Check for duplicate \label definitions
Python3 -c "
import re
from collections import Counter
tex = open('main.tex').read()
labels = re.findall(r'\\\\label\{([^}]+)}', tex)
dupes = \{k: v for k, v in Counter(labels).items() if v > 1}
for label, count in dupes.items():
print(f'WARNING: Duplicate label: \{label} (appears \{count} times)')
"
`
``Khắc phục mọi cảnh báo trước khi tiếp tục. Đối với quy trình làm việc dựa trên tác nhân: cung cấp lại đầu ra chktex cho tác nhân kèm theo hướng dẫn để thực hiện các bản sửa lỗi tối thiểu.
### Bước 7.5: Biên dịch lần cuối
``` bash
# Clean build
rm -f *.aux *.bbl *.blg *.log *.out *.pdf
latexmk -pdf main.tex
# Or manual (triple pdflatex + bibtex for cross-references)
pdflatex -interaction=nonstopmode main.tex
bibtex main
pdflatex -interaction=nonstopmode main.tex
pdflatex -interaction=nonstopmode main.tex
# Verify output exists and has content
ls -la main.pdf
`
``**Nếu quá trình biên dịch không thành công**: Phân tích tệp
.log
` để tìm lỗi đầu tiên. Các cách sửa lỗi phổ biến:
- "Trình tự điều khiển không xác định" → thiếu gói hoặc lỗi đánh máy trong tên lệnh
- "Thiếu $ được chèn" → ký hiệu toán học ngoài chế độ toán học
- "Không tìm thấy tệp" → sai đường dẫn hình hoặc thiếu tệp .sty
- "Trích dẫn không xác định" → thiếu mục .bib hoặc bibtex không chạy
### Bước 7.6: Yêu cầu cụ thể cho từng hội nghị| Địa điểm | Yêu cầu đặc biệt |
|-------|--------------------------|
| **NeurIPS** | Danh sách kiểm tra bằng giấy trong phụ lục, tóm tắt nội dung nếu được chấp nhận |
| **ICML** | Tuyên bố Tác động Rộng hơn (sau khi kết luận, không tính vào giới hạn) |
| **ICLR** | Yêu cầu tiết lộ LLM, thỏa thuận xem xét lẫn nhau |
| **ACL** | Phần Giới hạn bắt buộc, Danh sách kiểm tra NLP có trách nhiệm |
| **AAAI** | Tệp kiểu nghiêm ngặt - không có sửa đổi nào |
| **COLM** | Đóng góp khung cho cộng đồng mô hình ngôn ngữ |
### Bước 7.7: Gửi lại hội nghị & chuyển đổi định dạng
Khi chuyển đổi giữa các địa điểm, **không bao giờ sao chép phần mở đầu LaTeX giữa các mẫu**:
``` bash
# 1. Start fresh with target template
cp -r templates/icml2026/ new_submission/
# 2. Copy ONLY content sections (not preamble)
# - Abstract text, section content, figures, tables, bib entries
# 3. Adjust for page limits
# 4. Add venue-specific required sections
# 5. Update references
`
| Từ → Đến | Thay đổi trang | Điều chỉnh chính |
|----------|-------------|--------|
| NeurIPS → ICML | 9 → 8 | Cắt 1 trang, thêm Tác động rộng hơn |
| ICML → ICLR | 8 → 9 | Mở rộng thử nghiệm, thêm tiết lộ LLM |
| NeurIPS → ACL | 9 → 8 | Tái cấu trúc các quy ước NLP, thêm Hạn chế |
| ICLR → AAAI | 9 → 7 | Cắt giảm đáng kể, tuân thủ phong cách nghiêm ngặt |
| Bất kỳ → COLM | thay đổi → 9 | Điều chỉnh lại trọng tâm mô hình ngôn ngữ |
Khi cắt trang: di chuyển bản in thử sang phụ lục, cô đọng các công việc liên quan, kết hợp các bảng, sử dụng các cấu hình con.
Khi mở rộng: thêm các phần cắt bỏ, mở rộng các giới hạn, bao gồm các đường cơ sở bổ sung, thêm các ví dụ định tính.
**Sau khi bị từ chối**: Giải quyết những lo ngại của người đánh giá trong phiên bản mới, nhưng không bao gồm phần "thay đổi" hoặc tham chiếu đến bài gửi trước đó (đánh giá mù).
### Bước 7.8: Chuẩn bị sẵn sàng cho máy ảnh (Sau khi chấp nhận)
Sau khi chấp nhận, hãy chuẩn bị phiên bản sẵn sàng cho máy ảnh:
`
Camera-Ready Checklist:
- [ ] De-anonymize: add author names, affiliations, email addresses
- [ ] Add Acknowledgments section (funding, compute grants, helpful reviewers)
- [ ] Add public code/data URL (real GitHub, not anonymous)
- [ ] Address any mandatory revisions from meta-reviewer
- [ ] Switch template to camera-ready mode (if applicable — e.g., AAAI \anon → \camera)
- [ ] Add copyright notice if required by venue
- [ ] Update any "anonymous" placeholders in text
- [ ] Verify final PDF compiles cleanly
- [ ] Check page limit for camera-ready (sometimes differs from submission)
- [ ] Upload supplementary materials (code, data, appendix) to venue portal
`
### Bước 7.9: arXiv & Preprint Strategy
Đăng lên arXiv là thông lệ tiêu chuẩn trong ML nhưng có những cân nhắc quan trọng về thời gian và tính ẩn danh.
**Cây quyết định thời gian:**
| Tình huống | Khuyến nghị |
|----------||--------------|
| Gửi đến địa điểm mù đôi (NeurIPS, ICML, ACL) | Đăng lên arXiv **sau** thời hạn gửi, không phải trước đó. Việc đăng bài trước có thể vi phạm chính sách ẩn danh về mặt kỹ thuật, mặc dù việc thực thi có khác nhau. |
| Trình lên ICLR | ICLR rõ ràng cho phép đăng arXiv trước khi gửi. Nhưng đừng đặt tên tác giả vào bài nộp. |
| Giấy đã có trên arXiv, gửi đến địa điểm mới | Được chấp nhận ở hầu hết các địa điểm. KHÔNG cập nhật phiên bản arXiv trong quá trình đánh giá với những thay đổi tham chiếu đến đánh giá. |
| Giấy hội thảo | arXiv có thể sử dụng bất cứ lúc nào - các buổi hội thảo thường không mù đôi. |
| Muốn thiết lập ưu tiên | Đăng ngay lập tức nếu bạn lo ngại về việc thu thập tin tức - nhưng hãy chấp nhận sự cân bằng về tính ẩn danh. |
**Lựa chọn danh mục arXiv** (bài viết ML/AI):
| Danh mục | Mã | Tốt nhất cho |
|----------|------|----------|
| Học máy |
cs.LG
` | Phương pháp ML chung |
| Tính toán và Ngôn ngữ |
cs.CL
` | NLP, mô hình ngôn ngữ |
| Trí tuệ nhân tạo |
cs.AI
` | Lý luận, lập kế hoạch, đại lý |
| Thị giác máy tính |
cs.CV
` | Mô hình tầm nhìn |
| Truy xuất thông tin |
cs.IR
` | Tìm kiếm, đề xuất |
**Liệt kê danh mục chính + 1-2 danh mục được liệt kê chéo.** Nhiều danh mục hơn = mức độ hiển thị cao hơn nhưng chỉ liệt kê danh sách chéo khi thực sự có liên quan.
**Chiến lược tạo phiên bản:**
- **v1**: Đệ trình lần đầu (khớp với đệ trình hội nghị)
- **v2**: Sau khi chấp nhận với các chỉnh sửa sẵn sàng cho máy ảnh (thêm "được chấp nhận tại [Địa điểm]" vào phần tóm tắt)
- Không đăng v2 trong thời gian xem xét với những thay đổi phản hồi rõ ràng phản hồi của người đánh giá
``` bash
# Check if your paper's title is already taken on arXiv
# (before choosing a title)
pip install arxiv
Python -c "
import arxiv
results = list(arxiv.Search(query='ti:\"Your Exact Title\"', max_results=5).results())
print(f'Found \{len(results)} matches')
for r in results: print(f' \{r.title} (\{r.published.year})')
"
`
### Bước 7.10: Nghiên cứu đóng gói mã
Việc phát hành mã sạch, có thể chạy được sẽ làm tăng đáng kể số trích dẫn và sự tin cậy của người đánh giá. Mã gói cùng với việc gửi sẵn sàng cho máy ảnh.
**Cấu trúc kho lưu trữ:**
`
your-method/
README.md # Setup, usage, reproduction instructions
requirements.txt # Or environment.yml for conda
setup.py # For pip-installable packages
LICENSE # MIT or Apache 2.0 recommended for research
configs/ # Experiment configurations
src/ # Core method implementation
scripts/ # Training, evaluation, analysis scripts
train.py
evaluate.py
reproduce_table1.sh # One script per main result
data/ # Small data or download scripts
download_data.sh
results/ # Expected outputs for verification
`
``**Mẫu README cho mã nghiên cứu:**
`markdown
# [Paper Title]
Official implementation of "[Paper Title]" (Venue Year).
## Setup
[Exact commands to set up environment]
## Reproduction
To reproduce Table 1:
`bash scripts/reproduce_table1.sh
To reproduce Figure 2:
`Python scripts/make_figure2.py
## Citation
[BibTeX entry]
`
``**Danh sách kiểm tra trước khi phát hành:**
`
- [ ] Code runs from a clean clone (test on fresh machine or Docker)
- [ ] All dependencies pinned to specific versions
- [ ] No hardcoded absolute paths
- [ ] No API keys, credentials, or personal data in repo
- [ ] README covers setup, reproduction, and citation
- [ ] LICENSE file present (MIT or Apache 2.0 for max reuse)
- [ ] Results are reproducible within expected variance
- [ ] .gitignore excludes data files, checkpoints, logs
`
``**Mã gửi ẩn danh** (trước khi được chấp nhận):
`
``` bash
# Use Anonymous GitHub for double-blind review
# https://anonymous.4open.science/
# Upload your repo → get an anonymous URL → put in paper
`
---
## Giai đoạn 8: Sản phẩm bàn giao sau khi chấp nhận`**Mục tiêu**: Tối đa hóa tác động của bài viết được chấp nhận của bạn thông qua tài liệu thuyết trình và sự tham gia của cộng đồng.
### Bước 8.1: Poster hội nghị
Hầu hết các hội nghị đều yêu cầu một phiên áp phích. Nguyên tắc thiết kế áp phích:| Yếu tố | Hướng dẫn |
|----------|----------|
| **Kích thước** | Kiểm tra các yêu cầu về địa điểm (thường là 24"x36" hoặc A0 dọc/ngang) |
| **Nội dung** | Nhan đề, tác giả, đóng góp 1 câu, phương pháp hình, 2-3 kết quả chính, kết luận |
| **Dòng chảy** | Từ trên bên trái đến dưới cùng bên phải (mẫu Z) hoặc cột |
| **Văn bản** | Tiêu đề có thể đọc được ở khoảng cách 3m, nội dung ở khoảng cách 1m. Không có đoạn văn đầy đủ - chỉ có dấu đầu dòng. |
| **Số liệu** | Tái sử dụng số liệu giấy ở độ phân giải cao hơn. Phóng to kết quả chính. |
**Công cụ**: LaTeX (gói
`beamerposter
), PowerPoint/Keynote, Figma, Canva.
**Sản xuất**: Đặt hàng hơn 2 tuần trước hội nghị. Áp phích vải nhẹ hơn khi đi du lịch. Nhiều hội nghị hiện nay cũng hỗ trợ áp phích ảo/kỹ thuật số.
### Bước 8.2: Thảo luận hội nghị/Tiêu điểm
Nếu được trao giải trình bày miệng hoặc nổi bật:
| Kiểu nói chuyện | Thời lượng | Nội dung |
|----------|----------|----------|
| **Tiêu điểm** | 5 phút | Vấn đề, cách tiếp cận, một kết quả then chốt. Luyện tập đúng 5 phút. |
| **Bằng miệng** | 15-20 phút | Toàn bộ câu chuyện: vấn đề, cách tiếp cận, kết quả chính, sự cắt bỏ, những hạn chế. |
| **Trò chuyện hội thảo** | 10-15 phút | Thích ứng dựa trên đối tượng hội thảo - có thể cần thêm thông tin cơ bản. |
**Quy tắc thiết kế slide:**
- Một ý tưởng trên mỗi slide
- Thu nhỏ văn bản — nói chi tiết, đừng phóng đại chúng
- Hoạt hình các số liệu chính để xây dựng sự hiểu biết từng bước
- Kèm slide “mang về” ở cuối (đóng góp một câu)
- Chuẩn bị slide dự phòng cho các câu hỏi dự kiến
### Bước 8.3: Bài đăng trên blog/Mạng xã hội
Một bản tóm tắt có thể truy cập làm tăng đáng kể tác động:
- **Chủ đề Twitter/X**: 5-8 tweet. Dẫn đầu bằng kết quả chứ không phải bằng phương pháp. Bao gồm Hình 1 và hình kết quả chính.
- **Bài đăng trên blog**: 800-1500 từ. Viết cho những người thực hành ML, không phải người đánh giá. Bỏ qua chủ nghĩa hình thức, nhấn mạnh trực giác và ý nghĩa thực tế.
- **Trang dự án**: Trang HTML có tóm tắt, số liệu, demo, code link, BibTeX. Sử dụng trang GitHub.
**Thời gian**: Đăng trong vòng 1-2 ngày kể từ khi giấy xuất hiện trong quá trình tố tụng hoặc sẵn sàng cho máy ảnh arXiv.
---
## Hội thảo & Bài viết ngắn
Các tài liệu hội thảo và tài liệu ngắn (ví dụ: tài liệu ngắn ACL, tài liệu Kết quả) tuân theo cùng một quy trình nhưng có những ràng buộc và kỳ vọng khác nhau.
### Tài liệu hội thảo
| Bất động sản | Xưởng | Hội nghị chính |
|----------|----------|--------|
| **Giới hạn trang** | 4-6 trang (thông thường) | 7-9 trang |
| **Đánh giá tiêu chuẩn** | Thanh dưới cho đầy đủ | Phải đầy đủ, kỹ lưỡng |
| **Quy trình xem xét** | Thường mù đơn hoặc đánh giá nhẹ | Mù đôi, khắt khe |
| **Những gì có giá trị** | Ý tưởng thú vị, kết quả sơ bộ, vị thế | Câu chuyện thực nghiệm hoàn chỉnh với cơ sở vững chắc |
| **arXiv** | Đăng bất cứ lúc nào | Vấn đề về thời gian (xem chiến lược arXiv) |
| **Thanh đóng góp** | Hướng đi mới lạ, kết quả tiêu cực thú vị, công việc đang tiến triển | Tiến bộ đáng kể với bằng chứng mạnh mẽ |
**Khi nào nên nhắm mục tiêu hội thảo:**
- Ý tưởng ở giai đoạn đầu mà bạn muốn có phản hồi trước khi viết bài báo đầy đủ
- Kết quả tiêu cực không phù hợp với hơn 8 trang
- Vị trí phần hoặc ý kiến về một chủ đề kịp thời
- Nghiên cứu nhân rộng hoặc báo cáo khả năng tái tạo
### Các bài báo ngắn và kết quả của ACL
Địa điểm ACL có các loại gửi riêng biệt:
| Loại | Trang | Điều gì được mong đợi |
|------|-------|-----------------|
| **Giấy dài** | 8 | Nghiên cứu đầy đủ, cơ sở vững chắc, cắt bỏ |
| **Bài viết ngắn** | 4 | Đóng góp có trọng tâm: một quan điểm rõ ràng có bằng chứng |
| **Kết quả** | 8 | Công việc vững chắc mà suýt chút nữa đã bỏ lỡ hội nghị chính |
**Chiến lược viết bài ngắn**: Chọn MỘT tuyên bố và ủng hộ nó một cách triệt để. Đừng cố nén một bài viết dài thành 4 trang - hãy viết một bài viết khác, tập trung hơn.
---
## Các loại giấy ngoài ML thực nghiệm
Đường dẫn chính ở trên nhắm vào các bài viết ML theo kinh nghiệm. Các loại giấy tờ khác yêu cầu cấu trúc và tiêu chuẩn bằng chứng khác nhau. Xem [references/paper-types.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/skills/research/research-paper-writing/references/paper-types.md) để biết hướng dẫn chi tiết về từng loại.`###Bài lý thuyết`**Cấu trúc**: Giới thiệu → Sơ bộ (định nghĩa, ký hiệu) → Kết quả chính (định lý) → Bản phác thảo chứng minh → Thảo luận → Chứng minh đầy đủ (phụ lục)
**Sự khác biệt chính so với các bài báo thực nghiệm:**
- Đóng góp là một định lý, kết quả ràng buộc hoặc không thể xảy ra — không phải là số thực nghiệm
- Phần Phương pháp được thay thế bằng "Sơ bộ" và "Kết quả chính"
- Chứng minh là bằng chứng, không phải thí nghiệm (mặc dù việc xác nhận lý thuyết bằng thực nghiệm vẫn được hoan nghênh)
- Bản phác thảo chứng minh trong phần chính, phần chứng minh đầy đủ trong phần phụ lục là tiêu chuẩn thực hành
- Phần thí nghiệm là phần tùy chọn nhưng sẽ củng cố bài viết nếu nó xác nhận các dự đoán lý thuyết**Nguyên tắc viết bằng chứng:**
- Phát biểu các định lý một cách hình thức với tất cả các giả định rõ ràng
- Đưa ra trực giác trước khi đưa ra bằng chứng chính thức ("Cái nhìn sâu sắc quan trọng là...")
- Bản phác thảo chứng minh nên truyền tải ý chính trong trang 0,5-1
- Sử dụng môi trường
\begin\{proof}...\end\{proof}
- Đánh số các giả định và tham chiếu chúng trong các định lý: “Theo Giả định 1-3,…”
### Tài liệu khảo sát / hướng dẫn`**Cấu trúc**: Giới thiệu → Phân loại / Tổ chức → Nội dung chi tiết → Vấn đề mở → Kết luận`**Sự khác biệt chính:**
- Đóng góp là việc tổ chức, tổng hợp và xác định các vấn đề mở - không phải là phương pháp mới
- Phải toàn diện trong phạm vi (người đánh giá sẽ kiểm tra các tài liệu tham khảo còn thiếu)
- Yêu cầu phân loại hoặc khuôn khổ tổ chức rõ ràng
- Giá trị đến từ sự kết nối giữa các tác phẩm mà từng tờ giấy riêng lẻ không làm được
- Địa điểm tốt nhất: TMLR (theo dõi khảo sát), JMLR, Nền tảng và xu hướng trong ML, Khảo sát máy tính ACM
### Giấy tờ chuẩn`**Cấu trúc**: Giới thiệu → Định nghĩa nhiệm vụ → Xây dựng tập dữ liệu → Đánh giá cơ bản → Phân tích → Mục đích sử dụng & Hạn chế`**Sự khác biệt chính:**
- Bản thân sự đóng góp là chuẩn mực - nó phải lấp đầy khoảng trống đánh giá thực sự
- Tài liệu về tập dữ liệu là bắt buộc, không phải tùy chọn (xem Bảng dữ liệu, Bước 5.11)
- Phải chứng minh điểm chuẩn là thách thức (đường cơ sở không bão hòa nó)
- Phải chứng minh các tiêu chuẩn đo lường những gì bạn cho là nó đo lường (tính hợp lệ về mặt cấu trúc)
- Địa điểm tốt nhất: Theo dõi bộ dữ liệu & điểm chuẩn NeurIPS, ACL (giấy tờ tài nguyên), LREC-COLING
### Giấy tờ Vị trí`**Cấu trúc**: Giới thiệu → Bối cảnh → Luận điểm/Lập luận → Bằng chứng hỗ trợ → Phản biện → Hàm ý`**Sự khác biệt chính:**
- Đóng góp là lý lẽ, không phải kết quả
- Phải nghiêm túc phản biện
- Bằng chứng có thể là phân tích thực nghiệm, lý thuyết hoặc logic
- Địa điểm tốt nhất: ICML (position track), workshop, TMLR
---
## Tích hợp đại lý Hermes
Kỹ năng này được thiết kế cho đặc vụ Hermes. Nó sử dụng các công cụ, ủy quyền, lập kế hoạch và bộ nhớ của Hermes cho toàn bộ vòng đời nghiên cứu.
### Kỹ năng liên quan
Kết hợp kỹ năng này với các kỹ năng khác của Hermes cho các giai đoạn cụ thể:
| Kỹ năng | Khi nào nên sử dụng | Cách tải |
|-------|-------------|-------------|
| **arxiv** | Giai đoạn 1 (Đánh giá tài liệu): tìm kiếm arXiv, tạo BibTeX, tìm các bài viết liên quan thông qua Semantic Scholar |
skill_view("arxiv")
` |
| **phát triển theo hướng phụ** | Giai đoạn 5 (Soạn thảo): viết phần song song với đánh giá 2 giai đoạn (tuân thủ thông số kỹ thuật rồi đến chất lượng) |
skill_view("subagent-driven-development")
` |
| **kế hoạch** | Giai đoạn 0 (Thiết lập): tạo các kế hoạch có cấu trúc trước khi thực hiện. Viết vào
.Hermes/plans/
` |
`skill_view("plan")
` |
| **qmd** | Giai đoạn 1 (Văn học): tìm kiếm cơ sở tri thức địa phương (ghi chú, bảng điểm, tài liệu) thông qua tìm kiếm lai BM25+vector | Cài đặt:
`skill_manage("install", "qmd")
` |
| **lập biểu đồ** | Giai đoạn 4-5: tạo sơ đồ kiến trúc và hình vẽ dựa trên Excalidraw |
skill_view("diagramming")
` |
| **khoa học dữ liệu** | Giai đoạn 4 (Phân tích): Hạt nhân trực tiếp Jupyter để phân tích và trực quan hóa tương tác |
skill_view("data-science")
` |`**Kỹ năng này thay thế
`ml-paper-writing
** - nó chứa tất cả nội dung của văn bản ml cộng với toàn bộ quy trình thử nghiệm/phân tích và phương pháp tự động lý giải.
### Tham khảo công cụ Hermes| Công cụ | Cách sử dụng trong đường ống này |
|------|----------------------|
| **
`terminal
** | Biên dịch LaTeX (
`latexmk -pdf
), thao tác git, khởi chạy thử nghiệm (
`nohup Python run.py &
), kiểm tra quy trình |
| **
`process
** | Quản lý thử nghiệm nền:
`process("start", ...)
,
`process("poll", pid)
,
`process("log", pid)
,
`process("kill", pid)
` |
| **
`execute_code
** | Chạy Python để xác minh trích dẫn, phân tích thống kê, tổng hợp dữ liệu. Có quyền truy cập công cụ thông qua RPC. |
| **
`read_file
** / **
`write_file
** / **
`patch
** | Chỉnh sửa bài viết, kịch bản thí nghiệm, file kết quả. Sử dụng
`patch
` để chỉnh sửa có mục tiêu đối với các tệp .tex lớn. |
| **
`web_search
** | Khám phá văn học:
`web_search("transformer attention mechanism 2024")
` |
| **
`web_extract
** | Lấy nội dung bài viết, xác minh trích dẫn:
`web_extract("https://arxiv.org/abs/2303.17651")
` |
| **
`delegate_task
** | **Dự thảo phần song song** — sinh ra các tác nhân phụ riêng biệt cho mỗi phần. Ngoài ra để xác minh trích dẫn đồng thời. |
| **
`todo
** | Trình theo dõi trạng thái chính qua các phiên. Cập nhật sau mỗi giai đoạn chuyển tiếp. |
| **
`memory
** | Kiên trì đưa ra các quyết định quan trọng trong các phiên họp: khung đóng góp, lựa chọn địa điểm, phản hồi của người đánh giá. |
| **
`cronjob
** | Lên lịch giám sát thử nghiệm, đếm ngược thời hạn, kiểm tra arXiv tự động. |
| **
`clarify
** | Hỏi người dùng các câu hỏi nhắm mục tiêu khi bị chặn (lựa chọn địa điểm, khung đóng góp). |
| **
`send_message
** | Thông báo cho người dùng khi thử nghiệm hoàn tất hoặc bản nháp đã sẵn sàng, ngay cả khi người dùng không trò chuyện. |
### Mẫu sử dụng công cụ`**Giám sát thử nghiệm** (phổ biến nhất):
`
terminal("ps aux | grep <pattern")
→ terminal("tail -30 <logfile")
→ terminal("ls results/")
→ execute_code("analyze results JSON, compute metrics")
→ terminal("git add -A && git commit -m '<descriptive message' && git push")
→ send_message("Experiment complete: <summary")
`
``**Soạn thảo mặt cắt song song** (sử dụng ủy quyền):
`
delegate_task("Draft the Methods section based on these experiment scripts and configs.
Include: pseudocode, all hyperparameters, architectural details sufficient for
reproduction. Write in LaTeX using the neurips2025 template conventions.")
delegate_task("Draft the Related Work section. Use web_search and web_extract to
find papers. Verify every citation via Semantic Scholar. Group by methodology.")
delegate_task("Draft the Experiments section. Read all result files in results/.
State which claim each experiment supports. Include error bars and significance.")
`
``Mỗi đại biểu chạy như một **tác nhân phụ mới** không có ngữ cảnh chung — cung cấp tất cả thông tin cần thiết trong lời nhắc. Thu thập kết quả đầu ra và tích hợp.
**Xác minh trích dẫn** (sử dụng exec_code):
`
``` python
# In execute_code:
from semanticscholar import SemanticScholar
import requests`sch = SemanticScholar()
results = sch.search_paper("attention mechanism transformers", limit=5)
for paper in results:
doi = paper.externalIds.get('DOI', 'N/A')
if doi != 'N/A':
bibtex = requests.get(f"https://doi.org/\{doi}",
headers=\{"Accept": "application/x-bibtex"}).text
print(bibtex)
`
### Quản lý nhà nước với
`memory
` và
`todo
``**Công cụ
`memory
** — duy trì các quyết định quan trọng (giới hạn: ~2200 ký tự cho MEMORY.md):
`
memory("add", "Paper: autoreason. Venue: NeurIPS 2025 (9 pages).
Contribution: structured refinement works when generation-evaluation gap is wide.
Key results: Haiku 42/42, Sonnet 3/5, S4.6 constrained 2/3.
Status: Phase 5 — drafting Methods section.")
`
``Cập nhật bộ nhớ sau các quyết định quan trọng hoặc chuyển pha. Điều này vẫn tồn tại qua các phiên.
**Công cụ
`todo
** — theo dõi tiến trình chi tiết:
`
todo("add", "Design constrained task experiments for Sonnet 4.6")
todo("add", "Run Haiku baseline comparison")
todo("add", "Draft Methods section")
todo("update", id=3, status="in_progress")
todo("update", id=1, status="completed")
`
``**Giao thức khởi động phiên:**
`
1. todo("list") # Check current task list
2. memory("read") # Recall key decisions
3. terminal("git log --oneline -10") # Check recent commits
4. terminal("ps aux | grep Python") # Check running experiments
5. terminal("ls results/ | tail -20") # Check for new results
6. Report status to user, ask for direction
`
### Giám sát Cron với
`cronjob
``Sử dụng công cụ
`cronjob
` để lên lịch kiểm tra thử nghiệm định kỳ:
`
cronjob("create", {
"schedule": "*/30 * * * *", # Every 30 minutes
"prompt": "Check experiment status:
1. ps aux | grep run_experiment
2. tail -30 logs/experiment_haiku.log
3. ls results/haiku_baselines/
4. If complete: read results, compute Borda scores,
git add -A && git commit -m 'Add Haiku results' && git push
5. Report: table of results, key finding, next step
6. If nothing changed: respond with [SILENT]"
})
`
``**Giao thức [SILENT]**: Khi không có gì thay đổi kể từ lần kiểm tra cuối cùng, hãy phản hồi chính xác bằng
[SILENT]
. Điều này ngăn chặn việc gửi thông báo đến người dùng. Chỉ báo cáo khi có những thay đổi thực sự đáng biết.
**Theo dõi thời hạn**:
`
cronjob("create", {
"schedule": "0 9 * * *", # Daily at 9am
"prompt": "NeurIPS 2025 deadline: May 22. Today is \{date}.
Days remaining: \{compute}.
Check todo list — are we on track?
If <7 days: warn user about remaining tasks."
})
`
### Các kiểu giao tiếp`**Thời điểm thông báo cho người dùng** (thông qua
`send_message
` hoặc phản hồi trực tiếp):
- Lô thí nghiệm hoàn thành (có bảng kết quả)
- Phát hiện hoặc thất bại bất ngờ cần có quyết định
- Phần dự thảo đã sẵn sàng để xem xét
- Thời hạn đang đến gần với những nhiệm vụ chưa hoàn thành`**Khi KHÔNG thông báo:**
- Thử nghiệm vẫn đang chạy, không có kết quả mới →
[SILENT]
- Giám sát định kỳ không có thay đổi →
[SILENT]
- Các bước trung gian không cần chú ý`**Định dạng báo cáo** — luôn bao gồm dữ liệu có cấu trúc:
`
## Experiment: <name
Status: Complete / Running / Failed
| Task | Method A | Method B | Method C |
|------|---------|---------|---------|
| Task 1 | 85.2 | 82.1 | **89.4** |
Key finding: <one sentence
Next step: <what happens next
`
### Điểm quyết định cần có sự tham gia của con người
Sử dụng
`clarify
` cho các câu hỏi được nhắm mục tiêu khi bị chặn thực sự:
| Quyết định | Khi nào nên hỏi |
|----------|-------------|
| Địa điểm mục tiêu | Trước khi bắt đầu viết bài (ảnh hưởng đến giới hạn trang, đóng khung) |
| Đóng khung đóng góp | Khi tồn tại nhiều khung hợp lệ |
| Ưu tiên thử nghiệm | Khi danh sách TODO có nhiều thử nghiệm hơn thời gian cho phép |
| Sẵn sàng nộp hồ sơ | Trước khi nộp bản cuối cùng |
**KHÔNG hỏi về** (hãy chủ động, đưa ra lựa chọn, gắn cờ cho nó):
- Lựa chọn từ, sắp xếp phần
- Những kết quả cụ thể nào cần làm nổi bật
- Tính đầy đủ của trích dẫn (bản nháp với những gì bạn tìm thấy, ghi chú những khoảng trống)
---
## Tiêu chí đánh giá của người đánh giá
Hiểu những gì người đánh giá tìm kiếm giúp tập trung nỗ lực:
| Tiêu chí | Họ kiểm tra những gì |
|----------|----------------|
| **Chất lượng** | Tính đúng đắn về mặt kỹ thuật, tuyên bố được hỗ trợ tốt, đường cơ sở công bằng |
| **Rõ ràng** | Chữ viết rõ ràng, có thể tái tạo bởi các chuyên gia, ký hiệu nhất quán |
| **Ý nghĩa** | Tác động cộng đồng, nâng cao hiểu biết |
| **Tính độc đáo** | Những hiểu biết mới (không yêu cầu phương pháp mới) |**Tính điểm (Thang điểm 6 của NeurIPS):**
- 6: Chấp nhận mạnh mẽ — đột phá, hoàn hảo
- 5: Chấp nhận — vững chắc về mặt kỹ thuật, tác động cao
- 4: Chấp nhận ở ranh giới — đánh giá chắc chắn, hạn chế
- 3: Từ chối ở ranh giới — điểm yếu lớn hơn
- 2: Từ chối — lỗi kỹ thuật
- 1: Từ chối mạnh mẽ — các kết quả đã biết hoặc vấn đề đạo đức
Xem [references/reviewer-guidelines.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/skills/research/research-paper-writing/references/reviewer-guidelines.md) để biết hướng dẫn chi tiết, mối quan tâm chung và chiến lược bác bỏ.
---
## Các vấn đề thường gặp và giải pháp
| Vấn đề | Giải pháp |
|-------|----------|
| Tóm tắt quá chung chung | Xóa câu đầu tiên nếu nó có thể thêm bất kỳ bài viết ML nào. Bắt đầu với sự đóng góp cụ thể của bạn. |
| Giới thiệu vượt quá 1,5 trang | Chia nền thành Công việc liên quan. Đạn đóng góp tải trước. |
| Các thử nghiệm thiếu tuyên bố rõ ràng | Thêm: "Thử nghiệm này kiểm tra xem [tuyên bố cụ thể]..." trước mỗi yêu cầu. |
| Người phản biện thấy bài viết khó theo dõi | Thêm biển chỉ dẫn, sử dụng thuật ngữ nhất quán, tạo chú thích cho hình ảnh độc lập. |
| Thiếu ý nghĩa thống kê | Thêm thanh lỗi, số lần chạy, kiểm tra thống kê, khoảng tin cậy. |
| Phạm vi leo trong thí nghiệm | Mỗi thử nghiệm phải ánh xạ tới một xác nhận quyền sở hữu cụ thể. Cắt các thử nghiệm không. |
| Bài viết bị từ chối, cần gửi lại | Xem Gửi lại hội nghị trong Giai đoạn 7. Giải quyết những lo ngại của người đánh giá mà không tham khảo các đánh giá. |
| Thiếu tuyên bố tác động rộng hơn | Xem Bước 5.10. Hầu hết các địa điểm đều yêu cầu nó. “Không có tác động tiêu cực” gần như không bao giờ đáng tin cậy. |
| Đánh giá của con người bị chê là yếu | Xem Bước 2.5 và [references/human-evaluation.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/skills/research/research-paper-writing/references/human-evaluation.md). Báo cáo số liệu thỏa thuận, chi tiết người chú thích, bồi thường. |
| Người đánh giá đặt câu hỏi về khả năng tái tạo | Mã phát hành (Bước 7.9), ghi lại tất cả các siêu tham số, bao gồm hạt giống và chi tiết điện toán. |
| Bài viết lý thuyết thiếu trực giác | Thêm các bản phác thảo bằng chứng với các giải thích bằng ngôn ngữ đơn giản trước các bằng chứng chính thức. Xem [references/paper-types.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/skills/research/research-paper-writing/references/paper-types.md). |
| Kết quả âm tính/null | Xem Giai đoạn 4.3 về cách xử lý kết quả tiêu cực. Hãy coi các buổi hội thảo, TMLR hoặc việc sắp xếp lại làm phân tích. |
---
## Tài liệu tham khảo
| Tài liệu | Nội dung |
|----------|----------|
| [references/writing-guide.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/skills/research/research-paper-writing/references/writing-guide.md) | 7 nguyên tắc của Gopen & Swan, mẹo vi mô của Perez, lựa chọn từ ngữ Lipton, độ chính xác của Steinhardt, thiết kế hình ảnh |
| [references/citation-workflow.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/skills/research/research-paper-writing/references/citation-workflow.md) | API trích dẫn, mã Python, lớp CitesManager, quản lý BibTeX |
| [references/checklists.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/skills/research/research-paper-writing/references/checklists.md) | Yêu cầu NeurIPS 16 mục, ICML, ICLR, ACL, danh sách kiểm tra phổ biến trước khi nộp |
| [references/reviewer-guidelines.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/skills/research/research-paper-writing/references/reviewer-guidelines.md) | Tiêu chí đánh giá, cho điểm, mối quan tâm chung, mẫu phản bác |
| [references/sources.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/skills/research/research-paper-writing/references/sources.md) | Thư mục đầy đủ của tất cả các hướng dẫn viết, hướng dẫn hội nghị, API |
| [references/experiment-patterns.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/skills/research/research-paper-writing/references/experiment-patterns.md) | Mẫu thiết kế thí nghiệm, giao thức đánh giá, giám sát, khắc phục lỗi |
| [references/autoreason-methodology.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/skills/research/research-paper-writing/references/autoreason-methodology.md) | Vòng lặp lý do tự động, lựa chọn chiến lược, hướng dẫn mô hình, lời nhắc, giới hạn phạm vi, tính điểm Borda |
| [references/human-evaluation.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/skills/research/research-paper-writing/references/human-evaluation.md) | Thiết kế đánh giá con người, nguyên tắc chú thích, số liệu thỏa thuận, QC cộng đồng, hướng dẫn IRB |
| [references/paper-types.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/skills/research/research-paper-writing/references/paper-types.md) | Bài lý thuyết (viết chứng minh, cấu trúc định lý), bài khảo sát, bài benchmark, bài luận vị |
### Mẫu LaTeX
Các mẫu trong
`templates/
` dành cho: **NeurIPS 2025**, **ICML 2026**, **ICLR 2026**, **ACL**, **AAAI 2026**, **COLM 2025**.
Xem [templates/README.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/skills/research/research-paper-writing/templates/README.md) để biết hướng dẫn biên dịch.
### Các nguồn bên ngoài chính`**Triết học viết lách:**
- [Neel Nanda: How to Write ML Papers](https://www.alignmentforum.org/posts/eJGPTPbbFPZGLpjsp/highly-opinionated-advice-on-how-to-write-ml-papers)
- [Sebastian Farquhar: How to Write ML Papers](https://sebastianfarquhar.com/on-research/2024/11/04/how_to_write_ml_papers/)
- [Gopen & Swan: Science of Scientific Writing](https://cseweb.ucsd.edu/~swanson/papers/science-of-writing.pdf)
- [Lipton: Heuristics for Scientific Writing](https://www.approximatelycorrect.com/2018/01/29/heuristics-technical-scientific-writing-machine-learning-perspective/)
- [Perez: Easy Paper Writing Tips](https://ethanperez.net/easy-paper-writing-tips/)
**API:** [Semantic Scholar](https://API.semanticscholar.org/API-docs/) | [CrossRef](https://www.crossref.org/documentation/retrieve-metadata/rest-API/) | [arXiv](https://info.arxiv.org/help/API/basics.html)
**Địa điểm:** [NeurIPS](https://neurips.cc/Conferences/2025/PaperInformation/StyleFiles) | [ICML](https://icml.cc/Conferences/2025/AuthorInstructions) | [ICLR](https://iclr.cc/Conferences/2026/AuthorGuide) | [ACL](https://GitHub.com/acl-org/acl-style-files)