论文知识库与引用标注：当 AI 说「这段可以引用」的时候，它在想什么

3198 字

16 分钟

论文知识库与引用标注：当 AI 说「这段可以引用」的时候，它在想什么

2026-06-13

技术

论文工具

/

知识库

/

AI

/

面面通

/

全栈

为什么会做这个#

面面通最开始只是一个面试 + 简历的工具。后来加了论文润色、论文降重，用户用起来觉得还行。

但有个问题一直卡着。

润色的时候用户说：“帮我改一下这段，顺便看看有没有文献支持我的观点。”

问题在于——让 AI 自己引用，它真的会给你编文献。 编得像模像样，作者名、期刊名、年份全都有。一查，没这篇论文。

这不是 AI 的错。ChatGPT 从设计上就不是一个可靠的知识库检索器。它的引用是”看起来合理的文本模式”，不是”我真的读过这篇论文”。

所以面面通的论文知识库模块，目标是做一件事：

让引用可追溯、可验证、可清洗。

不是拒绝 AI 帮忙，而是让 AI 在一个受控的范围内工作——你只能引用已经上传到知识库的文献，而且必须经过三档证据分类，不能自己编。

整体链路#

一条数据从上传到最终引用，走完的完整路径是这样的：

1
上传 PDF/DOCX
2
  → 文本提取 (pdf.js / mammoth)
3
  → 智能分块 + 参考文献检测 + 关键词提取
4
  → 存入 IndexedDB (Dexie)
5
  → 构建全文搜索索引 (MiniSearch)
6
  → 用户写论文时，根据上下文检索相关片段
7
  → AI 证据分类：direct_support / background_only / irrelevant
8
  → 引用芯片渲染 + 导出时引用标记剥离

这条链路如果画出来，大概就是一台”不许 AI 瞎编”的引用流水线：

论文知识库引用流水线

好，拆开来讲。

第一步：上传 ≠ 存文件#

一开始我想得很简单：上传 PDF，存起来，搜索时全文匹配就行了。

实际写了才发现全是坑。

PDF 解析不是 `.toString()`#

PDF 的文本提取比你想象中麻烦得多。pdf.js 能提取文本，但提取出来的是按页面渲染顺序排列的文本片段——标题可能和正文混在一起，数学公式变成乱码，页眉页脚穿插在段落中间。

1
// paperParser.ts — PDF 解析
2
const pdfjsLib = await import('pdfjs-dist/legacy/build/pdf.mjs')
3
pdfjsLib.GlobalWorkerOptions.workerSrc = pdfWorkerUrl
4
const pdf = await pdfjsLib.getDocument({ data, useWorkerFetch: false }).promise
5

6
for (let i = 1; i <= pdf.numPages; i++) {
7
  const page = await pdf.getPage(i)
8
  const content = await page.getTextContent()
9
  const text = content.items
10
    .map(item => ('str' in item ? item.str : ''))
11
    .join(' ')
12
  pageTexts.push(text)
13
  page.cleanup()
14
}

DOCX 用的 mammoth，稍微好一点，但也要处理图片和表格里的文本。

参考文献区域识别#

解析出全文之后，参考文献区域必须剥离。原因很简单：如果你把参考文献列表也当成正文索引进去，搜索”深度学习”会匹配到参考文献标题而不是正文。

1
// paperChunker.ts — 参考文献区域检测
2
const REFERENCE_HEADING_RE = /^(参考文献|参考资料|引用文献|references|bibliography)/i
3
const YEAR_RE = /\b(?:19|20)\d{2}\b/g
4
const JOURNAL_MARK_RE = /\[(?:J|M|D|C|R|P|EB\/OL|OL)\]/gi
5

6
function isReferenceLikeText(text: string): boolean {
7
  // 如果一段文本里年份出现 4 次以上 + 期刊标记 2 次以上 → 判断为参考文献
8
  return (years >= 4 && (journalMarks >= 2 || pageRanges >= 3))
9
      || (years >= 5 && authorSeparators >= 12 && citationTitles >= 2)
10
}

这个方法不算完美，但实战效果够用。按标题匹配、按内容特征匹配两层防御，误杀率很低。

智能分块#

论文不能一整篇塞给 AI——上下文窗口有限。必须切成适当大小的块。

分块策略是：

1
function chunkPaper(fullText: string): PaperChunk[] {
2
  // 1. 按标题分段（# 一级标题 / 第一章 这种）
3
  const sections = splitByHeaders(stripReferenceSection(fullText))
4

5
  for (const sec of sections) {
6
    // 2. 跳过参考文献区域
7
    if (isReferenceSection(sec.section)) continue
8

9
    // 3. 长段落按自然段拆分，每块 800 字符左右
10
    const parts = splitLongChunk(sec.content)
11

12
    for (const part of parts) {
13
      // 4. 提取关键词（词频统计 + 停用词过滤）
14
      const keywords = extractKeywords(part)
15
      chunks.push({ order, section, content, keywords })
16
    }
17
  }
18
}

每个 chunk 还附带关键词，后面搜索时用得上。

第二步：搜索不是 Ctrl+F#

知识库没有 AI 帮你召回——你只能搜你已经上传的东西。

前端的搜索方案用了 MiniSearch，一个纯前端全文搜索库，跑在 IndexedDB 上层。

1
const ms = new MiniSearch({
2
  fields: ['content', 'keywords'],
3
  searchOptions: {
4
    boost: { keywords: 2 },  // 关键词匹配比正文匹配权重高
5
    prefix: true,
6
    fuzzy: 0.2,              // 允许 20% 的模糊匹配
7
  },
8
})

数据存在 Dexie（IndexedDB 的包装），不会上传到任何后端服务器。

搜索时根据不同任务类型做了查询增强：

1
const TASK_KEYWORDS = {
2
  paper_polish: ['论文', '润色', '学术', '写作', '表达'],
3
  ai_reduce:    ['降重', '重复', '相似', '改写', 'AI率'],
4
  plagiarism_reduce: ['查重', '抄袭', '重复率', '原创', '改写'],
5
  paper_qa:     ['问题', '回答', '解释', '分析', '方法'],
6
}

用户在润色的时候搜”卷积神经网络”，实际查询相当于 "卷积神经网络论文润色学术"——这能显著提升相关文献的排名。

第三步：证据分类 — 核心环节#

这就是最花心思的部分了。

搜出来的文献片段，不能说”跟你的论文关键词匹配了就直接引用”。万一只是关键词重复，实际内容风马牛不相及呢？

所以设计了一个证据分类环节。前端把检索到的 chunk 发给后端，后端调 AI 判断每段文献与当前论文的关系。

三档判定标准#

1
direct_support  ✓ — 片段能直接支撑当前论文的具体观点，可作为正文引用
2
background_only △ — 只提供背景参考，不应紧跟具体结论作为引用
3
irrelevant      ✗ — 仅关键词相似，不应使用

举个更具体的例子。

假设用户当前论文里有一句话：

卷积神经网络可以提升图像分类任务的准确率。

这时候知识库搜出来的片段不能无脑贴上去，而是要先分流：

如果片段明确说 CNN 在某个图像分类数据集上提升了准确率，那就是 direct_support，可以分配引用序号。
如果片段只是介绍 CNN 的卷积层、池化层这些基础概念，那就是 background_only，适合当背景，不适合紧跟这个结论。
如果片段只是碰巧出现了”神经网络”几个字，但内容讲的是文本分类，那就是 irrelevant，不能用。

证据分类三分流

这一步看起来有点啰嗦，但它其实是在防止一种很隐蔽的错误：关键词相似，不等于观点被支撑。

对应的 Java 实现：

1
private String buildPrompt(EvidenceRequest request, List<EvidenceRequest.Chunk> chunks) {
2
  sb.append("判定标准：\n");
3
  sb.append("- direct_support：片段能直接支撑当前论文中的具体观点、原因、方法、结论\n");
4
  sb.append("- background_only：片段只提供主题背景或术语参考\n");
5
  sb.append("- irrelevant：片段与当前观点关系弱或仅关键词相似\n");
6
  sb.append("只输出 JSON 数组。每项字段：index, supportLevel, confidence, supportedClaim, reason\n");
7
  sb.append("supportLevel 只能是 direct_support/background_only/irrelevant\n");
8
  sb.append("confidence 只能是 high/medium/low\n");
9
}

降级策略#

AI 接口可能超时、可能返回非法 JSON、可能干脆不可用。

所以证据分类必须有一个降级路径：

1
// AI 调用失败 → 按检索相关度分数做规则判断
2
private EvidenceResponse.Evidence fallbackEvidence(Chunk chunk, int index) {
3
  double score = chunk.getScore();
4
  if (score >= 0.72) {
5
    evidence.setSupportLevel("direct_support");   // 高分 → 可直接引用候选
6
    evidence.setConfidence("medium");
7
  } else if (score >= 0.42) {
8
    evidence.setSupportLevel("background_only");   // 中等分 → 背景参考
9
    evidence.setConfidence("medium");
10
  } else {
11
    evidence.setSupportLevel("irrelevant");        // 低分 → 不建议引用
12
    evidence.setConfidence("low");
13
  }
14
}

0.72 和 0.42 这两个阈值是拿实际论文数据跑了几轮试出来的，不一定通用，但在面面通的场景下效果不错。

引用索引的分配#

前端拿到分类结果后，只有 direct_support + 非 low 置信度 的 chunk 才会分配引用序号：

1
function assignCitationIndexes(chunks: ContextChunk[]): ContextChunk[] {
2
  let citationIndex = 1
3
  return chunks.map(chunk => {
4
    const allowCitation = chunk.supportLevel === 'direct_support'
5
                       && chunk.confidence !== 'low'
6
    return {
7
      ...chunk,
8
      citationIndex: allowCitation ? citationIndex++ : undefined,
9
    }
10
  })
11
}

没分配到序号的文献，在 prompt 里明确告诉 AI：不能标注引用。

第四步：引用渲染 — 把 [N] 变成看得见的东西#

AI 输出的文本里会带 [1]、[2] 这样的引用标记。前端要把它渲染成可点击的 chip，顺便生成参考文献列表。

1
export function renderCitations(text: string, citedChunks: CitedChunk[]) {
2
  // 把 [N] 替换为 chip HTML
3
  const html = text.replace(/\[(\d+)\]/g, (match, numStr) => {
4
    const index = parseInt(numStr)
5
    if (!chunkMap.has(index)) return match
6
    return `<span class="cite-chip" data-cite-index="${index}">${index}</span>`
7
  })
8

9
  // 按引用顺序生成参考文献列表
10
  const references = citedIndices.map(index => {
11
    const chunk = chunkMap.get(index)
12
    return `[${index}] ${chunk.paperTitle}`
13
  })
14

15
  return { html, references, citedIndices }
16
}

交互效果是：正文里出现带高亮的数字 chip，鼠标悬停显示文献标题，底部自动生成参考文献列表。

引用提取 — 从论文元数据中找信息#

上传时还会尝试从论文文本里提取引用元数据：

1
export function extractCitation(text: string): PaperCitation | null {
2
  // 提取中文名作者（2-4个字，连续出现）
3
  const cnMatch = text.match(/[一-鿿]{2,4}(?:[,，、\s]+[一-鿿]{2,4})+/)
4
  // 提取年份
5
  const year = text.match(/\b((?:19|20)\d{2})\b/)
6
  // 提取期刊名
7
  const journal = text.match(/\[J\]\s*[.。]?\s*(.+?)(?:[,，]|\s*\d{4}|\s*$)/)
8

9
  return { authors, year, journal, rawReference }
10
}

这个纯粹是正则匹配，不调 AI。所以准确率大概 70%，但对于生成参考文献列表来说，够了——不对的后面可以手动改。

导出时剥离引用标记#

导出 DOCX 的时候，引用标记必须去掉。不然 Word 里一堆 [1][2] 格式乱了。

1
export function stripCitationMarkers(text: string): string {
2
  return text.replace(/\[\d+\]/g, '')
3
}

就一行。但很容易漏掉，所以单独抽了个文件，所有导出路径统一调它。

第五步：安全与权限#

知识库涉及用户上传的文献全文，有几个安全设计值得提一下。

日志脱敏#

后端的知识库上下文处理器，日志里只打 chunk 数量，不打正文：

1
log.info("KB context sanitized: {} chunks, {} chars total", cleaned.size(), totalLength);

这是写在类注释里的硬性要求：

1
/**
2
 * 隐私要求：后端日志不得打印 contextChunks.content 正文。
3
 * 此类统一执行数量/长度限制和 null 清洗。
4
 */

知识库权限#

知识库默认对普通用户不可用。需要满足以下条件之一：

用户配置了自己的 AI API Key
用户是管理员
管理员在后台单独开放了权限

1
if (!hasOwnKey && !isAdmin && !isGranted) {
2
  throw new IllegalArgumentException(
3
    "知识库需要配置自己的 AI API Key，或由管理员单独开放后才能使用"
4
  )
5
}

原因很简单：知识库调 AI 做证据分类，如果用系统 Key 给所有用户免费用，额度撑不住。

上下文长度限制#

论文 chunk 送到 AI 之前还有一道清洗：

1
private static final int MAX_CHUNKS = 5;           // 最多 5 个 chunk
2
private static final int MAX_SINGLE_CONTENT_LENGTH = 1000;  // 每个最多 1000 字
3
private static final int MAX_TOTAL_LENGTH = 4000;  // 总共不超过 4000 字

超出部分截断，不够就从后面补。这样既保证 AI 能拿到足够的上下文，又不会突破 token 限制。

效果怎么样#

目前面面通的论文工具组（润色 + AI 降重 + 查重降重）共享这一个知识库模块。

实际使用中的几个数据：

一篇 10 页的 PDF 解析 + 分块 + 建索引，大约 3-5 秒
知识库搜索 + 证据分类 + 结果返回，平均 8-12 秒
证据分类的 AI 调用约消耗 2000-3000 tokens/次
三档分类中，direct_support 约占 40%，background_only 占 45%，irrelevant 占 15%

最大的改进是用户不再怀疑引用是 AI 编的了。因为引用列表明确来自”你上传的这几篇论文”，不会凭空冒出一篇你没见过的文献。

回头看的感想#

这个模块做下来，最深的体会是：

AI 能力越强，越需要给它画一个圈。

不是限制它发挥，而是告诉它：“你只能在这个圈里找答案，圈外的你碰都不要碰。” 圈画好了，输出才可靠。

知识库 + 证据分类就是那个圈。你上传的文献是边界，AI 的判断是栅栏——最终落到论文里的每一条引用，都有根可查。

当然还有能改进的地方。比如现在只做了文本检索，未来可以加上 embedding 向量检索，让语义匹配更准。DOCX 模板的引用标记格式保留也有优化空间。但目前的版本已经跑通了从”上传 → 检索 → 分类 → 渲染 → 导出”的完整链路，算是一个可以落地的方案。

如果你对面试模块、AiGateway 网关层或者 DOCX 格式保留导出感兴趣，面面通项目里还有不少类似的设计，完整代码在 GitHub 上。

如果这个项目的思路对你有帮助，点个 ⭐ 就行，对我来说是很大的鼓励。

论文知识库与引用标注：当 AI 说「这段可以引用」的时候，它在想什么

https://qiandaos.top/posts/mianmiantong-series/04-paper-knowledge-base-evidence/

作者

千岛寒流

发布于

2026-06-13

许可协议

CC BY-NC-SA 4.0

部分信息可能已经过时

AI 面试引擎：一个 Prompt 控制面试官、笔试邀请和结构化评分

AI 改写简历后，Word 格式没崩——折腾了 3 种方案才搞定

千岛の摸鱼小栈

为什么会做这个#

整体链路#

第一步：上传 ≠ 存文件#

PDF 解析不是 .toString()#

参考文献区域识别#

智能分块#

第二步：搜索不是 Ctrl+F#

第三步：证据分类 — 核心环节#

三档判定标准#

降级策略#

引用索引的分配#

第四步：引用渲染 — 把 [N] 变成看得见的东西#

引用提取 — 从论文元数据中找信息#

导出时剥离引用标记#

第五步：安全与权限#

日志脱敏#

知识库权限#

上下文长度限制#

效果怎么样#

回头看的感想#

PDF 解析不是 `.toString()`#