CiteTrue 对比 Google Gemini
很多引用问题就是从 Google Gemini 这类工具开始的,也有很多人回头拿它来查。直接问"这条引用是真的吗"有时确实管用 —— 尤其是开了联网搜索之后。麻烦在于:你分不清哪次是真查过,哪次是自信地猜的,因为两种回答的语气一模一样。
为什么我们的结论站得住
多数引用核查工具把判断整个交给大模型,再把模型说的话展示给你。可模型会产生幻觉 —— 这恰恰是这个品类存在的原因。所以我们把模型放在最后一步,而不是第一步。
- 01
1. 先解析,不猜
每条引用先由针对引用格式写的解析器拆成作者、标题、年份、期刊、DOI,而不是问模型「你觉得标题是哪段」。
- 02
2. 到权威库里查
拿解析出来的字段去 Crossref、OpenAlex 检索;没有 DOI 的再查开放网络。拿回来的是带真实标识符的真实记录。
- 03
3. 用确定性算法打分
候选记录用 Sørensen-Dice 对标题分词打相似度。标题分数过 0.7,并且作者也对得上,才算匹配成功;年份对不上会作为提示单独标出,不会被悄悄放过。同一条引用,每次算出来的分数都一样。
- 04
4. 到这一步才请模型出场
只有当确定性匹配没能找出可信结果时,才调用大模型 —— 让它读候选记录和原文,判断有没有对得上的。它是兜底,不是裁判。这个顺序决定了幻觉没有入口:轮到模型时,证据已经摆在桌面上了。
落到实处就是:这里标为可信的引用,是在标题和作者两个维度上匹配到了一条真实记录,而且你可以点开那条记录 —— 而不是模型觉得这条引用「看起来像真的」。
跑完一份参考文献要多久
核查一条引用意味着在多个来源里查好几次。一条一条排队跑,正是长参考文献让人等到不耐烦的原因。我们让它们并行跑,并且边跑边把结果推回来。
- 并行核查条数
- 应用内 20 条同时跑,API 放宽到 100 条
- 一份 50 条的参考文献
- 拆成三批并行查,而不是排成五十个队列
- 出结果的方式
- 逐条流式返回 —— 前面的结论已经能看,后面的还在跑
- 批量场景
- 一摞学生论文走 API,并发是应用内的五倍
各自擅长什么
| 对比项 | CiteTrue | Google Gemini |
|---|---|---|
| 本职工作 | 核查引用是否真实存在、是否支持引用它的那句话 | 回答问题、生成文本 |
| 会不会自己编出引用 | 不会 —— 每条结果都指向一条你能打开的数据库记录 | 会。这个品类存在的原因就是它 |
| 结论从哪来 | Crossref、OpenAlex 与网络来源,逐条列出 | 模型输出,有时附带搜索结果 |
| 一份 50 条的参考文献 | 一次粘贴,逐条给结论 | 要分批,而且上下文越长结果越飘 |
| 结果可复现 | 同一条引用结论一致,并留有报告记录 | 问两次可能得到两个答案 |
| 费用 | 每天 30 条免费;$9.99/月 1,000 条 | 有免费档,或约 $20/月,但不是按引用条数算 |
| 便捷度 | 浏览器扩展、macOS 客户端、API、MCP —— 可以直接接进 AI 工作流 | 聊天窗口,复制粘贴 |
| 额外一点 | — | 背后有 Google 搜索,确实有帮助 —— 但"搜到一个链接"不等于"这条引用核实过了"。 |
那到底该用哪个?
继续用 Google Gemini 写作和思考。只是别让它当引用的最后一道关 —— 提交前把参考文献过一遍 CiteTrue,你拿到的是逐条可查的记录,而不是一句让人安心的话。CiteTrue 还提供 MCP 服务,可以让 Google Gemini 直接调用它来核查,而不是靠猜。