Wiki 转 SFT 微调数据流水线 · 干货攻略

• 链接:https://x.com/omarsar0/article/2057114824467792189
• 分类:x-tips
• 来源:X @omarsar0
• 作者:Jay
• 更新:2026-08-23
• 仓库:dair-ai/wiki-sft

这是什么

dair-ai/wiki-sft 是一个配套仓库，完整复现了 @omarsar0（elvis）发表在 X 上的文章《Automating LLM Fine-Tuning with Fireworks Agent》的数据构建流程。

核心思路来自 Andrej Karpathy 的 LLM Wiki 概念：把个人知识库的"输出风格"通过 SFT 微调蒸馏进模型权重，而不是每次都在 prompt 里塞 system prompt + few-shot 示例。

仓库包含：

为什么值得关注

解决什么问题

场景：你维护着一个论文速读 wiki（或其他结构化知识库），希望模型按 wiki 的文风输出，但不想每次调用都塞一大段 system prompt。

传统方案：在 prompt 里塞风格说明 + 几个示例 → 每次推理都多付 token 账单，延迟增加，上下文窗口浪费。

这个方案：用 wiki 数据微调一个小模型（Qwen3-8B），把 wiki 的表达风格"蒸馏"进权重，一次推理只需传标题 + 摘要（几百 token），速度快、费用低、可直接在 agent 循环里内联调用。

谁在用、谁会感兴趣

• 个人知识管理开发者：维护自己的论文/笔记 wiki，想让模型适应自己的记录风格
• Agent 开发者：需要在 agent loop 里快速生成结构化摘要，不想开一个完整的 CoT pipeline
• 数据工程师：想了解"非结构化 wiki → 结构化 SFT 数据"的完整 pipeline 搭建方法

Andrej Karpathy 最早在 X 上提出这个方向——用合成数据 + 微调让 LLM"知道" wiki 内容而非每次靠 context。omarsar0 是第一个把这个方向工程化到"10 分钟 + 几分钱"量级的人。

核验过程

官方来源

1. GitHub 仓库 dair-ai/wiki-sft（MIT License） - 三个脚本源码全部可直接读取 - parse_2026.py：正则解析 markdown wiki，提取 ## Top AI Papers of the Week (Week X) - 2026 块中的表格行，提取 rank、title、summary、arxiv_url，输出 parsed_entries.json - fetch_abstracts.py：调用 http://export.arxiv.org/api/query?id_list=<ids>（官方 arXiv API），批量 25 个，间隔 3s（polite 访问），重试一次，输出 parsed_with_abstracts.json - build_jsonl.py：按 system prompt 模板（DAIR.AI 文风）+ user msg（标题+摘要）+ assistant msg（清理后的 summary）组装成 JSONL，seed=42 随机打乱，90/10 切分

2. @omarsar0 X 文章（原始分享） - 确认数据来源：DAIR.AI Top AI Papers of the Week wiki（2026 年） - 确认模型：Qwen3-8B（开源权重） - 确认平台：Fireworks Agent（ autonomous fine-tuning orchestration） - 确认效果：10 分钟 GPU 时间 + 几分钱计算成本，生成风格与 wiki 完全一致的摘要 - 确认输出可直接在 agent loop 内联调用（不需要 batch 作业）

3. arXiv Atom API（export.arxiv.org/api/query） - 确认是官方公开 API，允许批量查询（max 25 条/请求） - User-Agent 要求：脚本使用 dair-wiki-sft/1.0，符合 polite 规范

交叉验证

• Karpathy LLM Wiki 推文：omarsar0 在文章开头引用了 Karpathy 的 viral post 概念，确认这不是凭空发明，而是有明确学术/工程脉络的方向。
• Fireworks 官方文档：Fireworks Agent 确实是他们的 autonomous fine-tuning 产品，与仓库 README 描述一致。
• 脚本逻辑可复现：build_jsonl.py 中的 system prompt 明确写出"in the style of DAIR.AI's Top AI Papers of the Week"，与仓库描述的用途完全吻合。

关键数字核验

上手步骤

环境准备

# 克隆仓库
git clone https://github.com/dair-ai/wiki-sft.git
cd wiki-sft

# 安装依赖（仅 Python 标准库，无需额外 pip install）
# 脚本仅用 json, re, time, urllib, xml.etree.ElementTree, random, pathlib

Step 1：解析 Wiki（parse_2026.py）

脚本假设上游数据在实验路径下。如果自己运行，需要先准备原始 markdown 文件（格式：## Top AI Papers of the Week (Week X) - 2026 + 表格）：

from pathlib import Path
import json

# 如果直接使用仓库提供的 parsed_entries.json（需从 experiments 目录获取源文件）
# 或修改 SRC 路径指向你的 wiki markdown
SRC = Path("path/to/your/wiki-2026.md")
OUT = Path("parsed_entries.json")

核心正则逻辑（来自源码）：

WEEK_RE = re.compile(r"^## Top AI Papers of the Week \((.+?)\) - 2026\s*$", re.M)
ROW_RE  = re.compile(r"^\|\s*(\d+)\)\s\*\*(.+?)\*\*\s*-\s*(.+?)\s*\|\s*(.+?)\s*\|$", re.M)
ARXIV_RE = re.compile(r"\[Paper\]\((https?://arxiv\.org/abs/[^)\s]+)\)")

输出 parsed_entries.json，每条记录含 week、rank、title、summary、arxiv_url、paper_url。

Step 2：抓取 arXiv 摘要（fetch_abstracts.py）

python fetch_abstracts.py

关键参数（源码）： - 批量：25 条/请求 - 间隔：3s（最后一批除外） - 重试：失败后等 10s 再试一次 - 协议：arXiv Atom API（http://export.arxiv.org/api/query）

输出 parsed_with_abstracts.json。最终可用的 entries 数量取决于有多少条 wiki 记录附带了 arXiv 链接。

Step 3：构建 JSONL（build_jsonl.py）

python build_jsonl.py

System prompt 模板（直接决定模型输出风格）：

You write concise, structured summaries of AI research papers in the style of
DAIR.AI's Top AI Papers of the Week. Open with a one-paragraph lede that names
the authors' affiliation and the core contribution, then follow with three to
five bulleted takeaways. Each bullet begins with a bolded short label, a colon,
then a crisp explanation. Keep the tone analytical, specific, and free of hype.

User message 格式（每次推理时只需传这些 token）：

Paper: {title}

Abstract:
{arxiv abstract}

Write a Top AI Papers of the Week style summary.

输出： - train.jsonl — 90% 随机种=42，可直接提交 Fireworks 微调 - val.jsonl — 10% - all.jsonl — 含 _meta 字段（week、rank、title、arxiv_id），用于分析

Step 4：发起 Fireworks 微调

# 安装 Fireworks CLI
brew install fw-ai/firectl/firectl
firectl signin

# 上传数据集
source .env && firectl dataset create wiki-sft-2026 \
  --display-name "Wiki SFT 2026 (top 5 papers/week)" \
  train.jsonl \
  --api-key $FIREWORKS_API_KEY

# 发起 Agent session（全自动 orchestration）
source .env && firectl session create \
  --api-key $PI_API_KEY \
  -n "Run end-to-end supervised fine-tuning on qwen3-8b using dataset \
      accounts/<your-account>/datasets/wiki-sft-2026 and deploy the trained \
      model to a working inference endpoint. Use validation loss for evaluation."

Fireworks Agent 会自动完成：超参搜索 → 训练 → 模型上传 → 部署 inference endpoint。

Step 5：调用微调后的模型

# 测试部署（来自仓库 test_new_deployment.py）
python test_new_deployment.py

现在模型可以按 wiki 文风内联生成摘要，单次调用只需传几百 token（相比完整 system prompt + few-shot 节省约 500-1000 token/次）。

坑与适用边界

⚠️ 坑

1. arXiv API 限制：单请求最多 25 条 ID，间隔 3s，脚本已处理。若网络超时，需检查是否被限流。
2. 摘要依赖：没有 arXiv 链接的 wiki 条目无法生成可用训练数据，build_jsonl.py 会跳过无摘要的 entries。
3. 依赖 Fireworks 账户：完整 pipeline 需要 Fireworks API key + Pilot Agent（service account），不是纯开源的。
4. Seed 固定不等于数据固定：如果修改了上游 wiki 内容（添加新周/新条目），需要同步重新运行 parse_2026.py，否则新增数据不会进入数据集。

适用边界

• ✅ 强适用：个人论文 wiki、技术博客笔记、工程文档库——任何有固定输出风格的结构化文本集合
• ✅ 强适用：想用 agent loop 内联调用摘要生成，避免每次完整 system prompt 开销
• ❌ 不适用：wiki 格式不固定（无统一表格结构）——parse_2026.py 的正则强依赖特定 markdown 格式
• ❌ 不适用：追求泛化——微调后的模型只学会 wiki 文风，不适合做其他领域的摘要

扩展思路

如果不用 Fireworks，JSONL 数据可迁移到任何支持 SFT 的平台（Axolotl、llamafactory、OpenFineTune 等）：

# 检查 JSONL 格式（每行一个 JSON，messages 数组）
head -n 1 train.jsonl | python -m json.tool

一句话结论

dair-ai/wiki-sft 提供了一套完整的"结构化 wiki → chat 格式 SFT 数据"流水线，配合 Fireworks Agent 可在 10 分钟内把论文 wiki 的文风微调进 Qwen3-8B，适合想在 agent loop 里内联生成结构化摘要的开发者。

核验来源：GitHub dair-ai/wiki-sft 源码（MIT）、@omarsar0 X 文章、arXiv Atom API、Fireworks 官方文档、Karpathy LLM Wiki 推文。