1. 我遇到的问题
我给自己写了个论文管理工具，想把读过的论文攒成一个能用自然语言查询的库。检索本身不难，难在把论文变成能检索的东西。
arXiv 上的论文大多提供源码包，解开是个 tar.gz，里面是 .tex、.bib、.bbl 和图片。这类输入最好处理：章节写在 \section{} 里，公式在 \begin{equation} 里，参考文献在 \bibitem 里，作者和摘要在 \author{}、\abstract 里。直接从源码拿结构，比从 PDF 里猜要准得多。
麻烦的是只有 PDF 的那些。老论文、期刊投稿版、出版社版本都只给 PDF，而 PDF 又分三种：原生电子版能直接抽文本层；扫描件本质是图片，抽出来是空白或乱码；还有一类看着像电子版，实际是整页图片包在 PDF 容器里，文本层为空但肉眼完全正常。
第一版我只处理了原生 PDF，结果很干脆：TeX 包解不开，扫描件抽出空字符串，一份坏文档能让整批任务全部中断。
2. 为什么最后落在 u2a 上
我一开始想的是租个 GPU 机器。这个判断后来被推翻了，原因不复杂。
跑嵌入模型只需要几十兆参数，前向计算是稠密矩阵乘，算力早就过剩，真正卡住的是显存容量：批量上不去，长时间跑还会因为显存碎片化随机中断。我这个流水线的负载拆开看是三段，没有一段真的需要 GPU。
网关段是 FastAPI，处理请求、编排任务、调下游，I/O 密集，一台小机器就够。解析段是纯 CPU 计算：解压 TeX 包、PDF 逐页渲染成 PNG、判文本质量、切章节。检索段吃内存带宽，向量索引常驻内存，缓存命中率决定查询快慢。
真正决定体验的是解析段的批量吞吐和检索段的尾延迟。前者吃物理核数和向量指令宽度，后者吃内存带宽。这个形状对应的就是计算型或通用型实例。
u2a 用的是 AMD EPYC 9005 系列，Zen 5 架构，对我的负载有两处直接对上。一是原生 512 位 AVX-512 通路，Zen 4 时代的 AVX-512 是双 256 位发射拼出来的，Zen 5 在服务器端做成了完整 512 位执行单元，PDF 渲染和文本归一化这些路径都落在 SIMD 指令上，同频率下吞吐更高。二是单核性能没有因为核数多而被牺牲，解析任务是批量铺满核再靠单核收尾，批次完成时间由最慢那一页决定，单核太弱会直接拖长整体耗时。
内存配比也是个实际考虑。解析段的峰值内存主要来自并发渲染和 OCR 前的图片缓冲，可以按并发数直接算出来需要多少，不必为显存这种扩不了的东西留冗余。
3. 整体结构
┌──────────────────────────────┐
浏览器 / 手机 ───►│ u2a 实例上的网关容器 │
HTTP 接口 │ FastAPI :8002 → 宿主 :18002 │
└───────────┬──────────────────┘
│
┌─────────────────────┼─────────────────────┐
▼ ▼ ▼
┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│ 解析链路 │ │ 检索服务 │ │ 产物归档 │
│ TeX 源码包 │ │ 向量库 │ │ OSS │
│ PDF 文本层直抽 │ │ 稠密 + BM25 │ │ reports/ │
│ 质量异常→OCR │ │ RRF 融合 │ │ evidence/ │
│ 阿里云 OCR │ │ │ │ ocr/ │
└───────────────┘ └───────────────┘ └───────────────┘
│
└──────────────► SLS 日志（网关与业务日志）
网关、etcd、MinIO、向量库各跑一个容器，由一份启动脚本统一拉起。用容器是因为向量库和它的依赖版本耦合很紧，容器能把这套东西钉住，换机器时不用重配环境。
四个阿里云产品各自管一件事。ECS 承载全部容器和计算。OSS 存解析报告、引用证据片段、OCR 文本，按论文 id 分层。SLS 收网关和业务日志。阿里云 OCR 负责扫描件兜底，收的是渲染后的页面图片。
4. 解析链路
4.1 TeX 包：先找主文件，再展开
TeX 包解析的难点不在抽文本，在定位主文件和拼出完整文档。一个 arXiv 包解开可能是这样：
main.tex
sections/intro.tex
sections/method.tex
refs.bib
figures/fig1.pdf
neurips_2023.sty
主文件不能靠文件名猜，有叫 main.tex 的，有叫 paper.tex 的，还有 ms.tex。只能扫全部 .tex 找含 \documentclass 的那个，再递归展开 \input{} 和 \include{}。
import re
from pathlib import Path
_INPUT_RE = re.compile(r"\\(?:input|include)\{([^}]+)\}")
_DOCCLASS_RE = re.compile(r"\\documentclass(?:\[[^\]]*\])?\{([^}]+)\}")
def find_main_tex(root: Path) -> Path | None:
"""扫全部 .tex，返回含 \\documentclass 的那个。找不到说明不是完整包。"""
for path in sorted(root.rglob("*.tex")):
if path.is_file() and _DOCCLASS_RE.search(path.read_text(errors="ignore")):
return path
return None
def expand_inputs(path: Path, root: Path, seen: set[Path] | None = None) -> str:
"""递归展开 \\input 与 \\include，seen 用来防循环引用。"""
seen = seen or set()
if path in seen:
return "" # 循环引用直接截断，不能无限递归
seen.add(path)
text = path.read_text(encoding="utf-8", errors="ignore")
# 注释行里的 \input 不算数，先剥掉注释再匹配
text = re.sub(r"(?<!\\)%.*$", "", text, flags=re.M)
def repl(match: re.Match[str]) -> str:
name = match.group(1).strip()
target = (path.parent / name)
if target.suffix != ".tex":
target = target.with_suffix(".tex")
if not target.is_file():
return "" # 引用了不存在的文件，跳过而不是抛错
return expand_inputs(target, root, seen)
return _INPUT_RE.sub(repl, text)
两个地方必须处理。一是注释，% \input{draft} 是注释掉的，不剥掉会把草稿章节拼进来。二是循环引用，A \input B、B 又 \input A 的包我确实遇到过，没有 seen 集合会直接爆栈。
拿到完整源码后章节切分就简单了：
_SECTION_RE = re.compile(r"\\(section|subsection)\*?\{([^}]*)\}")
def split_sections(text: str) -> list[tuple[str, str]]:
"""按 \\section 切分，返回 [(标题, 正文)]。"""
matches = list(_SECTION_RE.finditer(text))
out = []
for i, m in enumerate(matches):
start = m.end()
end = matches[i + 1].start() if i + 1 < len(matches) else len(text)
out.append((m.group(2).strip(), text[start:end]))
return out
参考文献优先读 .bbl 而不是 .bib。bbl 是编译后的 \bibitem 列表，已经是最终形态，不用自己处理宏包差异：
_BIBITEM_RE = re.compile(r"\\bibitem(?:\[[^\]]*\])?\{([^}]+)\}")
def parse_bbl(text: str) -> dict[str, str]:
"""从 .bbl 抽 key → 条目原文。比解析 .bib 更可靠，因为 bbl 已是最终形态。"""
matches = list(_BIBITEM_RE.finditer(text))
refs = {
}
for i, m in enumerate(matches):
start = m.end()
end = matches[i + 1].start() if i + 1 < len(matches) else len(text)
refs[m.group(1)] = text[start:end].strip()
return refs
4.2 PDF：先判质量，再决定要不要 OCR
只有 PDF 的论文走另一条路。这里要判断的是抽出来的文本能不能用，而非能不能抽出来。我用三个可量化的信号：
_MOJIBAKE_CHARS = set("\ufffd\x00")
def text_quality(text: str) -> tuple[bool, str]:
"""返回 (是否可用, 原因)。不可用时上层走 OCR。"""
stripped = text.strip()
if len(stripped) < 800: # 短到不像一篇论文的正文
return False, "too_short"
mojibake = sum(1 for ch in stripped if ch in _MOJIBAKE_CHARS)
if mojibake / len(stripped) > 0.01: # 替换字符占比过高
return False, "mojibake"
cjk = sum(1 for ch in stripped if "\u4e00" <= ch <= "\u9fff")
# 中英文论文混排，纯符号或纯空格的页面判为无效
if cjk / len(stripped) < 0.01 and not any(c.isalpha() for c in stripped):
return False, "no_text"
return True, "ok"
800 字符是一页以上正文的下限，1% 的替换字符占比能区分偶发乱码和整页没抽到，CJK 与字母的联合判断是为了兼容中英文论文。这三个阈值把「看着不对就走 OCR」变成了可判断的条件。
质量不通过就走 OCR。前提是阿里云 RecognizeDocumentStructure 收的是图片不是 PDF，所以得先逐页渲染。
4.3 OSS 客户端
OSS 有官方 SDK，我最后手写签名，原因有两个具体场景：某些网络环境下要跳过 TLS 校验，改 SDK 意味着继承内部类；ListObjects 在部分节点存在策略同步延迟会偶发 403，需要对特定操作定制重试，而 SDK 的重试是全局配置，改一处影响全部。
V1 签名的待签名串是五行拼接：请求方法、Content-MD5、Content-Type、Date、资源路径。
import base64
import hashlib
import hmac
from email.utils import formatdate
from urllib.parse import quote, urlencode
# ListObjects 在部分节点会偶发 403（节点策略未同步，非权限问题）。
# 只对 ListObjects、只对 403 重试；Put/Get/Delete 的 403 是真没权限，重试没有意义。
_LIST_RETRY_MAX = 4
_LIST_RETRY_INTERVAL = 0.5
def _authorization(method: str, key: str, *, date: str, content_type: str,
bucket: str, ak_id: str, ak_secret: str) -> str:
# Content-MD5 留空，V1 签名允许；置空位仍要保留换行
string_to_sign = "\n".join((method, "", content_type, date, f"/{bucket}/{key}"))
signature = base64.b64encode(
hmac.new(ak_secret.encode("utf-8"), string_to_sign.encode("utf-8"), hashlib.sha1).digest()
).decode("ascii")
return f"OSS {ak_id}:{signature}"
def _url(key: str, *, endpoint: str, bucket: str, params: dict[str, str] | None) -> str:
# bucket 作子域名前缀：http://<bucket>.<endpoint>/<key>
# 不能拼成 <endpoint>/<bucket>/<key>——OSS 会把路径第一段当 bucket 名，报 NoSuchBucket
base = endpoint.strip().rstrip("/")
scheme, _, host = base.rpartition("//")
scheme = scheme or "http:"
url = f"{scheme}//{bucket}.{host}/{quote(key, safe='/')}"
if params:
url = f"{url}?{urlencode(params)}"
return url
Date 头必须是 RFC 1123 格式的 GMT 时间，用 email.utils.formatdate(usegmt=True) 生成。签名依赖当前时间，直接写断言会随运行时刻变化，所以时间提供者做成可注入的，测试里传固定值。
ListObjects 的重试单独抽出来，只对 403 生效：
def list_objects(self, prefix: str = "", *, max_keys: int = 100) -> list[OssObject]:
"""列举对象。403 按节点策略未同步重试，重试耗尽照常抛异常，不返回空列表掩盖问题。"""
params = {
"prefix": prefix, "max-keys": str(max_keys)}
for attempt in range(1, _LIST_RETRY_MAX + 1):
response = self._send("GET", "", params=params, content=None, content_type="")
if response.status_code == 403 and attempt < _LIST_RETRY_MAX:
self._sleep(_LIST_RETRY_INTERVAL)
continue
if response.is_error:
raise OssError("GET", f"?prefix={prefix}", response.status_code, response.text)
return _parse_list_result(response.text)
raise OssError("GET", f"?prefix={prefix}", 403, f"ListObjects 连续 {_LIST_RETRY_MAX} 次 403")
重试耗尽抛异常而不是返回空列表。返回空列表会让「没有对象」和「列举失败」在上层分不清，归档校验会静默通过，问题被推到更晚才暴露。
4.4 产物归档
三类产物按论文 id 分层写入，对象键设计成能批量前缀列举、能按期清理：
reports/<source>/<paper_id>/<task_id>.json
evidence/<source>/<paper_id>/<task_id>.json
ocr/<paper_id>/<digest>.txt
source 区分输入形态是 tex 还是 pdf，便于按来源统计解析成功率。
class ArtifactArchiver:
"""把解析产物写入 OSS。未配置时整体停用，不影响主流程。"""
def archive_result(self, *, task_id: str, paper_id: int, source: str, result: dict) -> None:
"""归档解析报告与其中的证据片段。
归档失败只记日志不抛出：结论已经落库，归档是旁路留存，
不能因为对象存储抖动把已经跑完的任务标成失败。
"""
if not self.enabled or self.client is None:
return
try:
self.client.put_object(
f"reports/{source}/{paper_id}/{task_id}.json",
json.dumps(result, ensure_ascii=False).encode("utf-8"),
content_type="application/json",
)
evidence = _collect_evidence(result)
if evidence:
self.client.put_object(
f"evidence/{source}/{paper_id}/{task_id}.json",
json.dumps(evidence, ensure_ascii=False).encode("utf-8"),
content_type="application/json",
)
except Exception as exc:
logger.warning("产物归档 OSS 失败 task_id=%s：%s: %s",
task_id, type(exc).__name__, exc)
归档是旁路不是主链路。做成弱依赖，对象存储抖动不会把已完成的任务标成失败；代价是归档可能缺失，所以另有一个校验任务定期比对数据库记录和 OSS 对象清单。
4.5 SLS 客户端
SLS 的 LOG 签名比 OSS 多两步：待签名串要带规范化后的 x-log- 头，资源路径要拼 logstore。
_API_VERSION = "0.6.0"
_SIGNATURE_METHOD = "hmac-sha1"
def put_logs(self, logs: list[dict[str, str]], *, timestamp: int | None = None) -> None:
"""写入日志。走 JSON 协议（非 protobuf）。
__time__ 必须是 JSON 整数，写成字符串会被拒：
PostBodyInvalid __time__ in log is not uint data type。
其余字段的值才必须是字符串。
"""
log_time = timestamp if timestamp is not None else int(time.time())
body = json.dumps({
"__topic__": self.settings.topic,
"__source__": self.settings.source,
"__logs__": [{
"__time__": log_time, **log} for log in logs],
}, ensure_ascii=False).encode("utf-8")
path = f"/logstores/{self.settings.logstore}/shards/lb"
# 这三个头是 SLS 必需的，且必须参与签名
log_headers = {
"x-log-apiversion": _API_VERSION,
"x-log-bodyrawsize": str(len(body)),
"x-log-signaturemethod": _SIGNATURE_METHOD,
}
canonicalized_headers = "".join(f"{k}:{v}\n" for k, v in sorted(log_headers.items()))
canonicalized_resource = f"/logstores/{self.settings.logstore}/shards/lb"
content_md5 = hashlib.md5(body).hexdigest().upper()
string_to_sign = (f"POST\n{content_md5}\napplication/json\n{date}\n"
f"{canonicalized_headers}{canonicalized_resource}")
# ...签名与发送
域名规则是另一个坑：project 是子域名前缀，不是 URL 路径。
# 正确：<project>.<endpoint>
host = f"{project}.{endpoint.removeprefix('https://').strip('/')}"
# 错误：<endpoint>/<project> —— 请求会落到默认 project 或直接 404
4.6 OCR 兜底
签名用 ACS3-HMAC-SHA256，和 OSS、SLS 的 HMAC-SHA1 完全是两套东西。
_ALIYUN_OCR_ACTION = "RecognizeDocumentStructure"
_ALIYUN_OCR_VERSION = "2021-07-07"
_SIGNATURE_ALGORITHM = "ACS3-HMAC-SHA256"
_MAX_IMAGE_BYTES = 10 * 1024 * 1024
# 全局并发上限：单个 PDF 内按页并发，但所有 PDF 共享这个上限
_ALIYUN_OCR_REQUEST_SEMAPHORE = BoundedSemaphore(2)
def _signed_openapi_headers(*, params, image_bytes, settings, url, now, nonce_factory):
host = urlparse(url).netloc
content_sha256 = hashlib.sha256(image_bytes).hexdigest()
headers = {
"content-type": "application/octet-stream",
"host": host,
"x-acs-action": _ALIYUN_OCR_ACTION,
"x-acs-content-sha256": content_sha256,
"x-acs-date": now().astimezone(UTC).strftime("%Y-%m-%dT%H:%M:%SZ"),
"x-acs-signature-nonce": nonce_factory(),
"x-acs-version": _ALIYUN_OCR_VERSION,
}
signed_headers = ";".join(k.lower() for k in sorted(headers, key=str.lower)
if _is_signed_header_key(k))
canonical_request = "\n".join((
"POST", "/", _canonical_query(params),
_canonical_headers(headers), signed_headers, content_sha256,
))
string_to_sign = "\n".join((
_SIGNATURE_ALGORITHM, hashlib.sha256(canonical_request.encode()).hexdigest(),
))
signature = hmac.new(settings.access_key_secret.encode(), string_to_sign.encode(),
hashlib.sha256).hexdigest()
headers["Authorization"] = (
f"{_SIGNATURE_ALGORITHM} Credential={settings.access_key_id},"
f"SignedHeaders={signed_headers},Signature={signature}"
)
return headers
并发控制用 BoundedSemaphore 而不是线程池，因为限制的是跨文档的全局在途请求数，不是单文档内部并行度。单个 PDF 内部按页 asyncio.gather 并发，所有 PDF 共享同一个上限，批量任务才不会把 OCR 服务打满。
渲染有硬限制：单页 PNG 不得超过 10 MB，超了接口直接拒。
def _render_page_png(page, *, dpi: int) -> bytes:
pixmap = render_page_pixmap(page, dpi)
image_bytes = bytes(pixmap.tobytes("png"))
if len(image_bytes) > _MAX_IMAGE_BYTES:
raise AliyunOCRResponseError("Aliyun OCR page image exceeds the 10MB API limit.")
return image_bytes
响应解析也要防：response.Data 是 JSON 字符串，得二次 json.loads，里面再取 prism_rowsInfo 的行文本，按 rowId 排序才能还原阅读顺序。直接按返回数组顺序拼接，双栏排版的论文会左右栏串行，读出来是乱序的。
5. 部署
u2a 上不用镜像仓库拉取，只能本地构建、导出、上传。小改动每次都走完整镜像流程成本太高，所以我用「热更新 → 验证 → commit 固化 → 重建」这条路径。
顺序不能颠倒：
# 1. 备份必须放宿主机：放容器内 /tmp 会被 docker rm -f 连同可写层一起删掉
BACKUP_DIR="/data/ossls_backup_${STAMP}"
for index in "${!TARGET_PATHS[@]}"; do
docker cp "${CONTAINER}:${TARGET_PATHS[$index]}" "${BACKUP_DIR}/${UPLOAD_NAMES[$index]}"
done
# 2. 写入容器可写层
docker cp "${UPLOAD_DIR}/oss_client.py" "${CONTAINER}:/app/shared/storage/oss_client.py"
# 3. 断言新代码可导入（此时失败自动回滚）
docker exec "${CONTAINER}" "${PYTHON}" -c "from shared.storage import OssClient"
# 4. 验证排在 rm -f 之前：可写层里的新代码在 rm -f 后不复存在
docker exec -e OSS_ACCESS_KEY_ID="${OSS_ACCESS_KEY_ID}" "${CONTAINER}" \
"${PYTHON}" /tmp/preflight/verify_oss_sls.py
# 5. 固化：把可写层提交成新镜像
docker commit "${CONTAINER}" "gateway:ossls-${STAMP}"
# 6. 必须 rm -f 重建而非 restart：restart 不更新 Config.Image，也不带新的 -e 参数
docker rm -f "${CONTAINER}"
bash "${START_SH}"
docker cp 只写可写层，docker rm 后消失，所以验证必须排在删除之前，验证通过必须 commit。颠倒任何一条，要么「验证通过了线上没生效」，要么代码直接丢了。
健康检查也有个陷阱：网关在容器内监听 8002，宿主机映射的是 18002。用宿主机 127.0.0.1:8002 探测会误判成启动失败，触发无谓回滚。
wait_health() {
for attempt in $(seq 1 45); do
# 必须在容器内探测：宿主机映射的是 18002
if docker exec "${CONTAINER}" "${PYTHON}" -c "
import urllib.request
urllib.request.urlopen('http://127.0.0.1:8002/health', timeout=5)
" >/dev/null 2>&1; then
return 0
fi
sleep 2
done
return 1
}
启动脚本的注入也得防。脚本里有多条 docker run，etcd、MinIO、向量库、网关各一条。我早期用 grep '-e ' 找插入锚点，结果匹配到 etcd 那条，把环境变量插错了地方。
# 正确做法：按容器名唯一定位，再校验该行确实含 'docker run -d '
GW_LINE="$(grep -n -- '--name gateway' "${START_SH}" \
| grep -v ':[[:space:]]*#' | cut -d: -f1)"
[ "$(echo "${GW_LINE}" | grep -c .)" -eq 1 ]
注入完还要复核：参数个数、值已展开、tag 已换、行数没变（变了说明插成了多行）、bash -n 语法通过。
6. 六条边界条件
bucket 必须在子域名位置。 <bucket>.<endpoint>/<key> 是唯一正确形式。拼成 <endpoint>/<bucket>/<key> 时 OSS 会把路径第一段当 bucket 名，返回 NoSuchBucket，而报错不会提示是拼接方式的问题，很容易误判成权限或 bucket 不存在。
ListObjects 的 403 不一定是权限问题。 部分节点的 bucket 策略存在同步延迟，List 操作会偶发 403。只有 ListObjects 的 403 值得重试，Put/Get/Delete 的 403 是真没权限。重试耗尽后必须抛异常，返回空列表会掩盖问题。
SLS 的 __time__ 必须是 JSON 整数。 写成字符串会被拒，报 PostBodyInvalid __time__ in log is not uint data type。同一条日志里其他字段的值反而必须是字符串。project 是子域名前缀，写成 URL 路径会落到默认 project 或直接 404。
OCR 接口收图片不收 PDF。 RecognizeDocumentStructure 的输入是单页图片，所以必须在 document 层做逐页渲染。渲染有 10 MB 上限，高 DPI 扫描页容易超限，要在渲染环节就检查而不是等接口拒绝。并发要设全局上限，只在文档内部并发而不设总量控制，批量任务会把服务打满。
docker cp 写的是可写层，rm -f 后即消失。 备份必须放宿主机，验证必须排在 rm -f 之前，验证通过必须 docker commit。docker restart 既不更新 Config.Image 也不带新的 -e 参数，改配置后必须 rm -f 重建。旧 tag 要从启动脚本读而不是从 docker inspect 读，原因也是 restart 不更新该字段。
断言必须先证明它会失败。 部署脚本里有一句「断言旧代码没有 shared.storage 模块」：如果旧代码本来就能导入，说明上一次已经装过，此时中止。这条断言如果不在旧代码上先跑一次确认它会失败，就证明不了任何事。永远通过的断言等于没有断言。
7. 几条判断
TeX 包和 PDF 的差距不在准确率，在结构是显式的还是推断的。 从源码拿 \section，章节边界是事实；从 PDF 拿章节，得靠字号、行距、编号模式做启发式判断，双栏排版和跨页标题会持续制造误判。所以我的链路优先走源码，PDF 只做兜底。这个顺序不是性能考虑，是正确性考虑——能拿到事实的时候不去推断。
文本质量判定比 OCR 本身更重要。 早期版本的问题是「该 OCR 的没 OCR，不该 OCR 的 OCR 了」。前者产生空字符串，后者白花配额还引入识别误差。三个阈值把这件事变成可判断的条件，比看着不对就走 OCR 可靠。
云产品的接入成本主要不在功能，在签名和协议细节。 OSS 用 HMAC-SHA1 的 V1 签名，SLS 用 LOG 签名，OCR 用 ACS3-HMAC-SHA256，三套规范互不相同，共同点是签名算错时服务端只返回笼统的 403 或 400，不告诉你哪个环节错了。手写客户端的价值在于每一步都可断点，能把「签名错误」拆成「待签名串拼错」还是「头没参与签名」。用官方 SDK 时这层被封装掉，出问题反而更难定位。
可回滚的部署流程，正确性由顺序而非代码保证。 热更新这套流程里没有一行复杂代码，全是 docker cp、docker exec、docker commit 这类原语。它之所以可靠，是因为备份在宿主机、验证在删除前、固化在验证后这三个顺序被固定住了。任何一个顺序调整都会破坏正确性，而且破坏方式很隐蔽——验证会通过，线上却不生效。
选型看瓶颈的形状，不看峰值算力。 这套系统没有一段需要 GPU：解析段吃向量指令宽度和物理核数，检索段吃内存带宽，网关段吃 I/O。u2a 的原生 512 位 AVX-512 对上解析段，单核性能对上尾延迟，内存配比对上并发渲染的峰值占用。负载拆开之后，实例族的取舍就是一道算术题。
