目录 展开 收起
不同模型是否适合你的笔记库，要靠相同输入和可追溯的结果判断。本文提供评测方法，没有实测模型排名、延迟或价格表；本地运行也需要硬件、电力和维护成本。
先确定比较哪条链路
ChatCrystal 的 摘要实现 先准备转录、运行经验门控，接受后才调用摘要模型；已有笔记会直接返回原 ID，不会因切换 LLM 自动覆盖。摘要落盘后还会生成向量并发现关系，这两步失败不等于摘要生成失败。因此“点击到全部完成”的时间与“模型生成摘要”的时间要分开记录。
若比较摘要模型本身，先冻结一份可见转录和相同的 SYSTEM_PROMPT、SummarizeSchema，在独立评测程序里对各模型提交相同内容；不要把重新点击已有会话当成重新生成。若比较应用全流程，则为每个配置建立独立测试数据目录，导入同一组来源副本，记录门控接受、过滤、摘要错误、向量状态和最终笔记。DATA_DIR 不会自动隔离来源或让客户端连接正确的实例，配置方法见 内存测量与隔离。
冻结样本与实际输入
选取已获准用于评测的中文、英文、调试、方案取舍、长会话和无可复用结论样本。为每份样本记录 ID、原始文件 hash、应用提交、模型完整标识、提示词版本和实际输入 hash；移除凭据并保留脱敏规则。只把需要的材料发送到获准的服务端。
转录处理 默认字符预算来自配置，不能当作精确 token 数。它选择每轮的部分助手消息；长会话保留首轮与末两轮，并按预算压缩中间部分，固定轮次仍可能让最终文本超出预算。评测中应保存实际生成的转录，而不是声称所有模型看到了完整原文。
sha256sum sample.jsonl transcript.txt system-prompt.txt这些文件名是评测记录约定，不是应用自动导出的文件。先从隔离评测程序保存对应内容，再运行 hash 命令。
用原文审查五个字段
| 字段 | 人工核对问题 |
|---|---|
| title | 能否指出具体问题，是否夸大结果？ |
| summary | 保留决策理由和适用条件了吗，有无新增事实？ |
| key_conclusions | 每条能否定位到可见转录，是否重复？ |
| code_snippets | 代码、版本和解释是否来自原文，是否可独立理解？ |
| tags | 能否用于检索，是否符合团队约定？ |
固定实现使用 generateText 与 Output.object，输出上限 4096 tokens、SDK 重试配置 3。Schema 限定字段类型；“20字”“3–5条”等写在 describe 与提示词里，并没有对应的长度或数量硬校验。成功解析 JSON 不能证明摘要事实正确，服务调用也可能失败。
可先规定每个维度“符合 / 部分符合 / 不符合”，隐藏模型名称后由两名审阅者定位证据，分歧回到原文裁定。没有可复用经验的样本单独评估门控，不给未调用摘要模型的结果打摘要质量分。评测目标、数据集与指标先确定再运行，可参考 OpenAI 评测方法。
将质量、失败与资源分别记账
每轮保存模型输出、字段评价、调用开始/结束时间、重试与错误，以及账单或可用的 token 用量；不从字符数推算确定费用。对本地模型同时记录硬件、量化与冷/热启动，对云端记录区域与网络条件。多次重复运行后报告分布和失败样本，不用一次成功代表稳定性。
队列限制的是队列任务启动，而非每秒只发一次模型请求；一项任务包含门控、摘要和其他调用，单次调用也会重试。它不保证免费额度或避免所有限流。先用 LLM 配置 验证连接，再用这套记录选择满足质量与资源要求的配置；不要从 provider 名称推导谁一定更好。