llm-wiki-compiler质量评估指南eval健康分、引用覆盖率与CI质量门设置【免费下载链接】llm-wiki-compilerThe knowledge compiler. Raw sources in, interlinked wiki out. Inspired by Karpathys LLM Wiki pattern.项目地址: https://gitcode.com/gh_mirrors/ll/llm-wiki-compilerllm-wiki-compilerllmwiki把原始资料编译成带引用链接的 wiki 知识库。编译只是第一步持续保障知识质量才是关键通过llmwiki eval命令你可以用一次运行拿到eval 健康分、引用覆盖率、引用精确度等量化指标并通过thresholds.yaml配置 CI 质量门让质量下降的编译在流水线中直接失败。本指南带你从零理解这些指标并搭好第一道质量防线。1. 为什么需要质量评估编译后的 wiki 是活的工件每次新增来源、重新编译都会带来新页面、更新的内容和变化的引用。没有质量门槛时一次重编译可能悄悄让引用精确度下滑、健康分下跌而你根本察觉不到。llmwiki 提供了两级检查工具源码位于 src/eval/ 目录命令作用需要 LLM 凭证llmwiki lint规则化检查断链、坏引用、空页面、过期页面否llmwiki eval在 lint 之上产出量化健康分、引用覆盖率等指标fast 套件不需要完整的命令参考见 docs/cli/lint-eval.mdx。2. 健康分health score怎么算llmwiki eval默认运行fast套件核心指标之一是0–100 的健康分它把所有 lint 规则的结果聚合为一个数字。扣分规则见 src/eval/health.ts很直观严重错误每次扣 4 分断开的 wikilink、损坏的引用、重复概念矛盾页面扣 2 分其他警告/信息各扣 1 分分数下限为 0上限 100100 分意味着 lint 什么都没查到一个刚编译完成、引用完整、无断链的 wiki 通常能拿到 90 分以上。按页面定位问题健康分布健康分告诉你整体怎么样而页面健康分布告诉你谁出了问题。每页按相同权重单独计分再归入四个档位档位分数区间healthy90–100adequate70–89needs_work50–69broken0–49报告会直接列出最差的页面及其主要问题维护者可以立刻知道从哪里下手。3. 引用覆盖率与引用精确度引用质量是 llmwiki 的立身之本eval 从两个方向度量它实现见 src/eval/citation-coverage.ts引用覆盖率citation coverage正文段落中至少携带一个^[...]引用标记的比例。标题、代码块、列表等非正文内容不计入。覆盖率越高内容越有据可查。引用精确度citation precision所有引用标记中指向sources/目录里真实存在的源文件的比例。低于 100% 说明有引用指向了已删除或改名的源文件。此外还有几个辅助指标源利用率有效来源中至少被一个页面引用的比例过低说明编译了但没进 wikiclaim 级引用率带具体行号区间如^[source.md:42-58]的引用比例越高越精确引用支持度仅 full 套件抽样(论断, 源文段)对交给裁判模型按 0无支持/1部分支持/2完全支持打分结果缓存在.llmwiki/eval/citation-cache.jsonl重复运行只重判新增样本4. 设置 CI 质量门thresholds.yaml 完整步骤这是本指南最重要的部分——把指标变成流水线里的硬约束。第一步创建阈值文件在项目根目录创建.llmwiki/eval/thresholds.yaml所有字段均可选不写即跳过该项检查health_score: 85 citation_coverage_percent: 70 citation_precision_percent: 90 citation_support_mean: 1.4 # 仅 --suite full 时检查 source_utilization_rate: 0.9 source_warnings_max: 0 claim_level_citation_rate: 0.5字段含义速查字段范围说明health_score0–100最低健康分citation_coverage_percent0–100最低引用覆盖率citation_precision_percent0–100最低引用精确度citation_support_mean0–2裁判平均分仅 full 套件检查source_utilization_rate0–1最低源利用率source_warnings_max整数允许的最大被排除来源数claim_level_citation_rate0–1最低带行号引用比例第二步理解退出码行为llmwiki eval每次都会打印完整报告当项目存在thresholds.yaml时它会逐项比对任何一项不达标就以非零状态码退出CI 将其视为失败步骤判定逻辑见 src/eval/thresholds.ts。llmwiki eval --suite fast # 阈值全过退出码为 0否则非零--suite fast不需要任何 LLM API 调用免费且足够快适合放进常规 CI--suite full会消耗 token建议留给周期性深度检查。第三步接入 CI在流水线中安装并运行即可- name: Install llmwiki run: npm install -g llm-wiki-compiler - name: Check wiki quality run: llmwiki eval --suite fast⚠️ 注意如果配置了citation_support_mean但 CI 一直跑 fast 套件该阈值会被静默跳过。5. 用历史趋势跟踪质量变化每次 eval 运行都会向.llmwiki/eval/history.jsonl追加一行记录并自动与上一次运行做差值对比llmwiki eval history # 查看所有历史记录的趋势表 llmwiki eval history --n 10 # 只看最近 10 条 llmwiki eval report # 重打最近一次报告不重新运行报告中的增量形如health_score: 91 (−4)一眼就能看出这次重编译是提升了还是降低了质量。趋势数据还包括页面数、来源数、wiki 字符数等语料统计回归一目了然。6. 上手建议先宽松再收紧官方指南docs/guides/ci-quality-gates.mdx给出的最佳实践新 wiki 先设宽松阈值如health_score: 60citation_coverage_percent: 50只拦严重退化定期查看趋势表llmwiki eval history帮你确认当前水平逐步提高门槛随着引用卫生改善把阈值向目标质量线靠拢fast 管日常full 管深度CI 每次跑 fast每周或发版前跑一次 full 套件复核引用支持度小结关注点用什么快速发现断链、坏引用llmwiki lint量化整体质量llmwiki eval健康分 引用覆盖率定位具体坏页面页面健康分布报告阻断质量回退thresholds.yaml CI 非零退出追踪长期趋势llmwiki eval history掌握 eval 健康分、引用覆盖率与 CI 质量门这套组合拳你的 wiki 就能像代码有测试一样拥有可持续的质量保障。更多细节可参阅 docs/cli/lint-eval.mdx 与 docs/guides/ci-quality-gates.mdx。【免费下载链接】llm-wiki-compilerThe knowledge compiler. Raw sources in, interlinked wiki out. Inspired by Karpathys LLM Wiki pattern.项目地址: https://gitcode.com/gh_mirrors/ll/llm-wiki-compiler创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考