用LLM构建可复现研究流水线：从文献调研到RAG知识库-平芜编程栈

用 LLM 做研究：从“聊天问答”到“可复现研究流水线”

在 Hacker News 的技术讨论区里，经常能看到一个问题：“How do you use LLMs for your research？”这个问题看似简单，实际问的是：大语言模型在真实研究工作中到底应该放在哪个环节，是当搜索引擎用，还是当协作分析者用，还是干脆只用来整理笔记。

过去一年里，我的答案发生了明显变化。最初我只是把 LLM 当成一个“能聊天的搜索框”，后来逐渐发现，研究工作和普通问答的最大区别在于：研究需要可追溯、可复现、可验证。基于这个转变，我把自己在文献调研、实验设计、代码辅助、论文写作和知识库维护这几个环节中使用 LLM 的完整方法整理了出来。这篇文章会给出具体工作流、提示词模板、环境配置、代码示例，以及我在实际使用中踩过的坑。

适合的读者有两类。一类是高校学生、科研人员和工程师，想把论文阅读、实验代码、文献笔记这类工作交给 LLM 提效；另一类是正在做 RAG、Agent 和 LLM 应用开发的开发者，想找一个相对完整的“知识库 + Agent”落地场景。

1. 先理解 LLM 在研究工作中到底适合做什么

1.1 研究者真正需要的不是“答案”，而是“证据链”

普通问答场景中，用户问“什么是 Transformer”，LLM 给出一个通顺解释就满足了。但研究场景完全不同。比如你问“LoRA 在低秩矩阵维度选择上有什么经验法则”，如果模型只是给出一段流畅表达，却没有说明这个结论来自哪篇论文、在哪个数据集上验证、实验设置的秩是多少、有没有对比 baseline，那么这段回答对研究工作的价值就很低。

研究的核心是证据链：结论必须有来源，来源必须能追溯到论文、代码、数据集或实验日志。这也是为什么很多研究者用了一段 LLM 之后觉得“它说得挺对，但我不敢引用”。问题不在于 LLM 不能帮助研究，而在于使用方式还停留在问答模式。

正确思路是把 LLM 定位成“研究管线中的多个组件”，每个组件只负责一环，且每一环都保留原始材料。比如文献筛选环节，LLM 负责从 100 篇论文中提取候选列表，但它必须给出每篇论文的标题、DOI、摘要原文和筛选理由，研究员再人工抽查。这样 LLM 就不是替代判断，而是扩展处理范围，判断权仍然在自己手里。

1.2 研究工作流中适合 LLM 介入的五个环节

根据我的实践，LLM 在研究中的价值主要体现在五个环节：

文献调研与筛选：从大量论文中快速抽取主题、方法、数据集、结论，生成结构化对比表。

论文阅读与摘要：对单篇论文进行分段摘要、术语解释、数学推导补充和“反事实提问”。

实验代码辅助：生成 PyTorch 训练脚本、数据处理脚本、消融实验配置，以及解释报错信息。

写作与润色：在作者自己完成论证逻辑的前提下，帮助改写句式、统一术语、检查段落衔接。

知识库维护：把读过的论文、实验笔记、技术博客沉淀到本地知识库，后续通过检索复用。

这五个环节有一个共同特点：它们都适合“批处理”和“结构化”，不适合“一锤子买卖式问答”。换句话说，LLM 在研究里最好的使用方式不是一次性对话，而是把研究过程拆成多个可以重复执行的步骤。

1.3 不要用 LLM 做研究中的哪些事情

避免使用的场景同样重要。我不会让 LLM 决定研究选题，因为选题需要领域嗅觉和文献积累；不会让它生成实验结论，因为结论必须来自真实实验数据；不会让它直接生成引文条目，因为 LLM 幻觉可能制造出不存在的文献；也不会让它独立设计实验对照组，这需要精确理解任务和数据集分布。

这些边界不是保守，而是对研究负责。LLM 是研究者能力的放大器，不是研究责任的替代品。

2. 搭建一个 LLM 研究环境：本地推理与 API 的选型逻辑

2.1 先明确需求再做选型：不是所有环境都能用云端 API

部署方式和模型选型都要看具体研究场景。

如果处理的是公开论文、摘要和通用代码，可以直接使用云端 API，速度快，模型能力强，成本也可控。如果涉及未公开数据、内部实验结果、患者数据或企业隐私数据，就必须考虑本地部署或私有化 API 网关。

在常见项目中，我建议按下面的方式判断：

场景	推荐方式	原因
公开论文摘要、通用技术调研	云端 API	模型强、速度快、无需维护 GPU
实验笔记、内部代码库、专利未公开内容	本地模型或私有化部署	数据不出内网，合规风险低
批量处理大量短文本	先小样本验证再批量	控制成本和幻觉率
需要稳定复现的长期任务	固定模型版本和温度参数	保证结果可比较

需要注意的是，不要只看模型名，还要看推理服务的参数设置、版本锁定方式和日志记录方式。研究环境里，“这次结果和上次不一样”很容易导致整个验证过程失效。

2.2 本地部署最小方案：Ollama + Python 示例

如果选择本地部署，推荐一个适合研究场景的最小技术栈：Ollama 负责模型运行，Python 通过 HTTP API 调用，SQLite 保存结构化结果。整个链路不复杂，但足够支撑起研究辅助工具。

安装 Ollama 后，先拉取一个可用的对话模型：

ollama pull qwen2.5:7b ollama pull llama3.1:8b

拉取完成后，使用下面的 Python 脚本验证本地推理环境：

import requests import json response = requests.post( "http://localhost:11434/api/generate", json={ "model": "qwen2.5:7b", "prompt": "请用三句话总结这篇论文的贡献：标题是《Attention Is All You Need》。", "stream": False, "options": { "temperature": 0.2, "top_p": 0.9, "max_tokens": 512 } } ) data = response.json() print(data["response"])

这个脚本的关键点有三个：

temperature 设置成 0.2，用于摘要类任务，减少随机性；如果任务是头脑风暴或候选方案生成，再调到 0.7 以上。

stream 设为 False，方便第一次调试，避免流式输出把日志刷花。

max_tokens 不能太小，否则长摘要会被截断；也不能太大，否则一次请求耗时失控。

本地部署的优势是数据可控、无限调用、离线可用；代价是 GPU 显存有限，7B 到 14B 级别的模型在复杂推理上不如云端大模型。所以我的实际策略是：本地模型负责批量文本处理，云端模型负责复杂推理和长上下文分析。

2.3 环境变量与 API Key 管理

不管用哪个云厂商的模型服务，都要做到两件事：API Key 不进代码库、模型版本和 base_url 显式配置。

推荐使用 .env 文件管理配置：

# .env LLM_API_KEY=your_api_key_here LLM_BASE_URL=https://api.example.com/v1 LLM_MODEL=gpt-4o-mini LLM_TEMPERATURE=0.2

然后在 Python 中通过 pydantic-settings 或 dotenv 加载：

from dotenv import load_dotenv import os load_dotenv() config = { "api_key": os.getenv("LLM_API_KEY"), "base_url": os.getenv("LLM_BASE_URL"), "model": os.getenv("LLM_MODEL"), "temperature": float(os.getenv("LLM_TEMPERATURE", "0.2")), }

不要为了省事把 key 直接写在代码里。研究项目经常要分享代码，Key 一旦进入 git 历史，即使后面删掉，也可能已经被别人拉取。

3. 文献调研工作流：用 LLM 批量筛选论文并生成结构化速览表

3.1 从关键词到候选论文列表

文献调研的第一步通常是从一个宽泛问题开始，比如“基于大模型的代码生成研究中，检索增强到底怎么和模型结合”。直接把这个宽泛问题丢给 LLM，很容易得到一堆泛泛而谈的论文推荐，其中还夹杂着幻觉出来的文献。

更可控的做法分成两步。第一步用传统检索方式获取候选列表；第二步再让 LLM 对候选列表做结构化处理。

传统检索可以从这些入口开始：

Google Scholar 搜索关键词
arXiv API 按标题、摘要检索
Semantic Scholar API 获取引用数据
已读论文的参考文献列表

得到候选论文标题后，交给 LLM 的任务不是“推荐相关论文”，而是“根据我给出的论文标题和摘要，整理成指定字段的结构化表格”。这样 LLM 的幻觉空间被大大压缩，因为它只能基于输入内容输出。

下面是一个通过 arXiv API 拉取候选论文的 Python 示例：

import urllib.parse import urllib.request import xml.etree.ElementTree as ET query = urllib.parse.quote("retrieval augmented generation code generation") url = f"http://export.arxiv.org/api/query?search_query=all:{query}&start=0&max_results=10" with urllib.request.urlopen(url) as resp: data = resp.read().decode("utf-8") ns = {"atom": "http://www.w3.org/2005/Atom"} root = ET.fromstring(data) papers = [] for entry in root.findall("atom:entry", ns): title = entry.find("atom:title", ns).text.strip().replace("\n", " ") summary = entry.find("atom:summary", ns).text.strip().replace("\n", " ") link = entry.find("atom:id", ns).text papers.append({"title": title, "summary": summary, "url": link}) print(len(papers))

这一步的目标是把原始论文信息变成结构化输入，为下一步 LLM 处理做准备。

3.2 给 LLM 一个固定模板，让输出可以直接入库

获取论文原始信息后，构造如下提示词，要求 LLM 输出 JSON。关键在于：强调必须基于给定摘要，不允许补充外部知识。

你是一个科研助理。请根据下面的论文列表，输出 JSON 数组。 每篇论文需要包含： - title: 论文标题 - method: 方法的核心思想，不超过 50 字 - dataset: 使用的数据集或实验场景，如果没有则写 unknown - baseline: 对比的基线方法，如果没有则写 unknown - result: 主要实验结论，不超过 80 字 - limitation: 作者提到的局限或你从摘要中合理推断的局限，不超过 50 字 - url: 原始链接 要求： 1. 只能基于提供的摘要内容，不能补充外部知识； 2. 如果摘要中没有相关信息，填写字符串 "unknown"； 3. 不要输出除 JSON 之外的任何内容。 论文列表： {papers_json}

把上一节得到的 papers 列表转成 JSON 传入，就能得到结构化结果：

[ { "title": "Example Paper", "method": "提出一种检索增强的代码生成框架", "dataset": "HumanEval", "baseline": "Codex", "result": "在 HumanEval 上提升约 5 个百分点", "limitation": "仅针对单函数粒度，未验证长文件场景", "url": "http://arxiv.org/abs/xxxx" } ]

使用这种“固定模板输出”的价值在于：不同时间跑同一批论文，输出格式一致；结果可以直接写入 SQLite、CSV 或 Notion 表格；后续可以用脚本继续筛选，而不需要反复回到对话里找内容。

3.3 常见坑：论文筛选阶段的幻觉来源

在文献调研阶段，最常遇到的问题有三个。

第一个是要求 LLM “推荐论文”时生成不存在的文献。推荐做法是颠倒流程：先由检索系统给出真实论文列表，LLM 只负责整理和理解，不负责生成参考文献条目。

第二个是摘要中明明没有说明数据集，LLM 却自作主张填了 “ImageNet”。解决办法是在提示词中强制规定：信息缺失时填 unknown，不要猜测。

第三个是让 LLM 一次性处理超过上下文窗口的论文数量，导致结果被截断或遗漏。解决办法是把论文分批处理，每批 5 到 10 篇，全部处理完后再合并。

4. 深度阅读单篇论文：让 LLM 从“总结者”变成“对话式解释器”

4.1 分段摘要与术语解释

读论文时直接让 LLM “帮我总结这篇论文”效果并不好，因为对陌生领域来说，总结通常只覆盖了最容易懂的部分，难懂的方法细节仍然没解决。

我推荐的做法是把论文按结构拆开处理，一次只让 LLM 解释一个部分。比如把 Abstract、Method 中的公式、Experiment 表格分别输入。

对 Method 部分，可以用这样的提示词：

你是这个研究方向的资深审稿人。请用最容易理解的语言解释以下方法段落。 要求： 1. 先指出该方法解决的核心问题； 2. 再用“输入 -> 处理 -> 输出”的格式描述流程； 3. 解释至少两个关键术语； 4. 给出一个最小示例，说明输入和输出长什么样； 5. 如果段落包含数学公式，用直白语言解释每个符号的含义。 原文： [粘贴论文段落]

这个提示词的设计思路是：不给 LLM 太宽泛的任务，而是要求它从多个角度解释同一个段落。这样更容易发现它是否真的理解了，或者只是在套话。

4.2 反事实提问：检验 LLM 是否真理解方法

检验模型是否理解一个方法，最好的方式不是让它复述，而是让它回答“如果去掉某个模块会怎样”“如果修改某个超参数会怎样”。这种反事实提问对研究者自己也很有用，能帮助想清楚实验中的变量关系。

例如读完一篇对比学习论文后，可以向 LLM 提问：

如果训练阶段去掉投影头（projection head），直接使用编码器输出的特征做对比损失，模型效果会发生什么变化？请从训练目标和特征空间两个角度分析。

这类问题不一定需要模型给出绝对正确的答案，而是通过它的回答帮助研究者发现之前忽略的机制。关键在于，模型给出的任何推理都不能作为实验结论，必须通过真实实验验证。

4.3 常见坑：上下文过大导致的错误

把整篇 20 页论文一次性塞进 prompt，经常出现两种问题：上下文过长导致部分内容被截断；模型把前面段落的信息错误迁移到后面段落。

实际处理时建议按章节切割。一篇论文拆成 introduction、method、experiment、conclusion 四段，分别阅读。如果使用支持超长上下文的模型，仍然建议分段提问，因为分段提问能让模型集中注意力，回答质量明显更高。

5. 把知识沉淀成 RAG 知识库：Obsidian 与 LLM Wiki 的落地组合

5.1 为什么要从“一次性对话”走向“知识库”

研究过程中最浪费的事情，是几个月前读过的论文、记过的实验细节、踩过的环境坑，全部散落在不同对话窗口和文档里。等到真需要时，想找却找不到，或者只能凭记忆重新搜索。

解决思路是把 LLM 的产出沉淀为结构化文档，再通过 RAG 让这些文档变成可持续查询的知识库。简单说，就是用向量数据库或支持全文检索的工具保存笔记，后续问答时先检索相关笔记，再让 LLM 基于检索结果回答。

在个人知识库场景里，Obsidian 加 Markdown 是一个非常合适的基础设施。所有笔记都是纯文本，没有平台锁定；可以通过双链组织论文、实验、代码之间的关系；也能配合社区插件实现全文检索和向量化。

我之前在项目里用过这样一个组合：

Obsidian 作为笔记编辑和浏览层
Markdown 文件保存结构化的论文笔记
向量化脚本把笔记写入本地向量库
一个本地 Python CLI 完成“检索 + LLM 回答”

5.2 一个轻量 RAG 流程示例

假设你已经把论文笔记整理成了 Markdown 文件，下面是用 LangChain 搭建轻量检索问答的示例。

from langchain_community.document_loaders import DirectoryLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import Chroma loader = DirectoryLoader("notes/", glob="**/*.md") docs = loader.load() splitter = RecursiveCharacterTextSplitter( chunk_size=500, chunk_overlap=50 ) chunks = splitter.split_documents(docs) embedding = HuggingFaceEmbeddings(model_name="BAAI/bge-small-zh-v1.5") vectorstore = Chroma.from_documents(chunks, embedding) retriever = vectorstore.as_retriever(search_kwargs={"k": 4})

检索器准备好之后，提问流程是：先检索出与问题最相关的 4 个片段，再把片段和问题组合成 prompt，交给 LLM 回答。关键点在于提示词中要说明“只能基于检索内容回答”，这样可以减少幻觉。

from langchain.chains import RetrievalQA from langchain_openai import ChatOpenAI llm = ChatOpenAI( model="gpt-4o-mini", temperature=0.1, openai_api_key=config["api_key"], openai_api_base=config["base_url"], ) qa = RetrievalQA.from_chain_type( llm=llm, retriever=retriever, chain_type="stuff" ) result = qa.invoke("LoRA 中 rank 的选择对下游任务效果有什么影响？") print(result["result"])

这个 RAG 流程适合个人知识库规模，几百篇 Markdown 笔记完全够用。生产环境如果文档数量增长到几十万，还需要引入增量索引、密度聚类、混合检索和评价集，但核心思想不变：先检索，再回答。

5.3 向量化是 RAG 最重要的环节

很多 RAG 项目效果差，问题出在向量化而不是大模型。常见的错法是把整篇论文作为一个向量，结果检索时匹配精度极低；或者没有做分块调优，导致语义断裂。

建议先做三件事：

确认 chunk_size 是否适合文档类型。学术论文适合 300 到 800 字的分块，代码文档适合更小的块。

确认文本清洗规则。Markdown 标题、链接、代码块是否被保留或剔除，会直接影响向量语义。

构建一个包含 10 到 30 条真实问题的评测集，人工判断每条检索结果是否相关，再迭代分块和 embedding 模型。

不要在没有评测集的情况下盲目换 embedding 模型。模型 A 在某个公开基准上分数高，不代表在你自己领域的数据上更准。

5.4 常见坑：RAG 检索到不相关片段时的表现

当检索结果不相关时，LLM 依然可能给出流畅答案，这是 RAG 最隐蔽的坑。表面上看起来回答了，实际上内容来自模型内部知识，而不是笔记。

排查方式很简单：在返回结果中同时输出引用的原文片段，人工检查“回答是否真的来自片段”。如果经常出现“检索片段完全不相关但回答很流畅”的情况，优先检查分块大小和 embedding 模型是否匹配，而不是检查 LLM 参数。

更稳妥的提示词模板：

你是一个研究助理。请仅根据下面提供的资料回答问题。 资料： {context} 问题：{question} 要求： 1. 如果资料中找不到答案，直接回答“资料中没有相关内容”； 2. 不要使用资料之外的常识补充； 3. 回答末尾列出你参考的资料文件名。

6. 用 LLM 辅助实验代码：从生成训练脚本到解释报错

6.1 让 LLM 生成可配置的训练脚本

写论文实验代码时，经常需要针对不同数据集、不同模型写很多结构类似的脚本。完全手写浪费时间，完全让 LLM 生成又容易失控。我的做法是：先写好一个模板，让 LLM 在模板基础上补全，而不是从零生成。

下面是一个最小 PyTorch 训练脚本模板：

import argparse import torch from torch import nn from torch.utils.data import DataLoader def parse_args(): parser = argparse.ArgumentParser() parser.add_argument("--epochs", type=int, default=10) parser.add_argument("--batch_size", type=int, default=32) parser.add_argument("--lr", type=float, default=3e-4) parser.add_argument("--device", type=str, default="cuda") return parser.parse_args() def main(): args = parse_args() # TODO: 加载数据集 # TODO: 初始化模型 # TODO: 定义优化器和损失函数 # TODO: 训练循环 pass if __name__ == "__main__": main()

把这个模板放到提示词中，要求 LLM 完成数据加载、模型定义和训练循环。这样生成结果受模板约束，不会被模型自由发挥到完全不可用。

6.2 排错示例：显存不足、野卡和数据未对齐

用 LLM 辅助代码排错时，给模型的上下文越接近真实日志，效果越好。不要只复制一行错误消息，要把完整堆栈、关键代码片段、输入数据的 shape 一并提供。

例如常见错误 CUDA out of memory 的处理思路：

现象：训练开始时出现 RuntimeError: CUDA out of memory。 环境：显卡显存 8GB，batch_size=32，输入图片是 224x224，模型是 ResNet50。 请列出可能导致显存不足的配置项，并按排查优先级排序。

这种问法能帮助研究者快速定位：是 batch_size 太大，是模型太大，还是 DataLoader 的 num_workers 导致额外开销。

实际排错时，我会按下面的顺序检查：

输入数据 shape 是否正确，是否意外创建了巨大的中间张量。
batch_size 是否在当前显存限制范围内。
优化器是否有主模型之外的额外状态。
是否在不需要梯度时忘记使用 torch.no_grad()。
是否有模型前向过程产生了未释放的计算图。

这些内容本身也可以整理成笔记，放进知识库，后续遇到相同问题直接检索。

6.3 常见坑：LLM 生成代码不是“可直接运行”的代名词

LLM 生成的实验代码经常存在三个问题：数据集路径是假的；模型与论文描述不一致；训练循环缺少 eval 阶段。

推荐处理方式是把生成代码当作“第一版草稿”，必须完成以下检查后才能运行：

数据集的下载、缓存和预处理是否真实存在
模型输入维度是否与数据维度匹配
是否保存最佳 checkpoint，而不是只保存最后一个
评价指标是否在测试集上计算
随机种子是否固定，确保多次运行可比较

尤其是随机种子，实验代码不固定种子，论文里的“提升 2 个百分点”很可能是随机波动，而不是方法带来的提升。

7. 从对话记录到论文写作：LLM 在写作环节的正确位置

7.1 LLM 能写句子，但不能替你论证

写作阶段最容易犯的错误，是让 LLM 直接生成整段 Related Work 或 Method 描述。这样写出的文字缺少作者自己的判断和逻辑链，而且一旦模型幻觉了某篇论文，引用就成了大问题。

我的用法是，在论文结构确定之后，让人工先把每段的“论点 + 论据 + 句子逻辑”写成提纲，然后用 LLM 做这些事：

把口语化提纲改写成学术书面表达
压缩冗长段落
统一术语
检查段落之间的过渡是否自然

比如下面这个提示词：

下面是我的一段论文草稿，请帮我做学术化润色，不要增加新的技术内容，不要新增参考文献，不要改变句子顺序。 要求： 1. 保持原意； 2. 使用更正式、更简洁的学术表达； 3. 如果段落中有重复表达，合并； 4. 直接输出润色后的段落。 草稿： [粘贴段落]

这个提示词的关键是加了三道约束：不增加新内容、不新增引用、不改变句子顺序。这样 LLM 的发挥空间被压缩到“语言表达”层面，而不是“内容创作”层面。

7.2 用 LLM 做术语一致性检查

论文写作到后期经常出现术语不统一的问题，比如一会儿写 “low-rank adaptation”，一会儿写 “LoRA”，一会儿写 “低秩适配”。人工检查容易遗漏，可以交给 LLM 做一次术语一致性扫描。

下面是一篇论文的多个段落。请找出我使用的核心术语，检查是否存在同一概念使用不同术语的情况。 输出格式： - 概念：概念解释 - 使用过的术语列表 - 推荐统一术语 论文段落： [粘贴内容]

这项任务风险低，即使模型判断不完全准确，也能作为人工检查的起点。

7.3 常见坑：润色后引入错误

LLM 润色可能引入两个问题：一是把一个技术概念换成了自己发明的等价表达，导致原文含义变化；二是通过改写句子顺序改变了段落逻辑。

防范方式有两个。第一，润色后必须用 diff 工具对比原稿和修改稿，逐条确认改动；第二，在提示词中禁止结构性和概念性修改，只允许语言层面调整。

8. 研究级 LLM 使用的评估方法：如何确认“用 LLM 是真的有帮助”

8.1 不要凭感觉判断质量，建立小型评估集

很多人在使用 LLM 辅助研究时，靠“感觉回答不错”来判断质量。这种方式在简单问题上够用，但在研究方法评估上完全不够。

可以建立一个小型评估集。选取 20 到 30 个真实问题，这些问题可以来自你实际研究过程中的提问，覆盖文献理解、实验设计、代码排错、概念解释等类型。

对每个问题，保存三条信息：

问题原文
LLM 的回答
人工评分与评语

评分维度建议分为相关性、准确性、可追溯性和可操作性四项，每项 1 到 5 分。每两周评估一次，观察不同模型、不同提示词方案的变化。

8.2 评估清单：从答案倒查引用

研究场景中对 LLM 回答的评估，必须把“可追溯性”作为核心指标。具体检查方式如下：

检查项	通过标准
事实是否有来源	关键结论能对应到论文、文档或实验记录
引用是否真实存在	如果提到论文，能在 arXiv 或出版社查到
回答是否基于给定资料	闭卷回答和开卷检索回答不要混淆
是否区分推测与事实	模型应明确标注“这是我的推断”
结果是否可复现	相同输入、相同参数下多次运行结果稳定

如果这五个检查项大部分不通过，说明当前答案不能进入研究流程，只能当思路启发。

8.3 常见坑：把“流畅”当成“准确”

大模型生成的答案天然通顺，这一点会让不熟悉技术细节的人低估幻觉风险。在研究场景里，越是流畅但不给来源的回答，越要警惕。培养自己的检查习惯：拿到一个回答，先问“这个说法来自哪里”，再去验证。

验证方式包括：在原文中检索关键句、查看模型是否列举了可定位的来源、自己复现一次计算。没有验证流程，LLM 在研究里就会变成一个高风险的信息源。

9. 生产级研究知识库：从个人脚本到可维护系统

9.1 学习环境与生产环境的差异

本地跑一个检索问答脚本只是学习验证。真正要变成团队可用、长期维护的研究系统，还需要考虑很多工程问题。

学习环境里可以直接把一段 Markdown 一次性写入 Chroma；生产环境需要一个增量更新的管道，新论文入库时只处理新增部分。

学习环境里可以忽略权限问题；生产环境要区分私有实验数据和公开论文数据，可能需要上不同的模型和不同的访问控制。

学习环境里用一条 prompt 直接问答；生产环境要加日志、版本、评测和回滚机制，每次 prompt 模板改动都要记录，防止“换了模板后结果变了”却查不到原因。

9.2 给研究系统增加日志与版本控制

研究系统的运行记录本身也是研究数据。建议在一开始就给每次 LLM 调用保存一份完整 JSON 日志，记录以下字段：

{ "timestamp": "2025-06-01T10:00:00Z", "task": "literature_review", "model": "gpt-4o-mini", "temperature": 0.2, "prompt_version": "v3", "input": "", "output": "", "latency_ms": 1234, "token_count": 3456 }

保存到本地后，可以按 prompt_version 统计不同版本的输出质量，也可以复盘某个错误结果到底是输入问题还是模型问题。这是把 LLM 应用从“试玩”升级到“研究工具”的关键一步。

9.3 可复用清单：研究系统上线前检查

上线一个 LLM 辅助研究系统前，至少完成以下检查：

是否所有外部依赖都锁定了版本
API Key 是否已从代码仓库移除
是否记录了每次请求的模型名、参数和输入输出
是否设置最大 token 和请求超时
是否对输出结果做了非法字符清洗
是否建立小型评估集并测过基线
是否保留原始论文整理结果，而不是只保留模型输出摘要
是否明确哪些任务允许 LLM 参与，哪些任务禁止 LLM 参与
是否有批量任务失败后的重试和告警机制
是否有回滚方案，比如 prompt 模板改动后如何回到上一版本

10. 从 Andrej Karpathy 的“LLM Wiki”范式到个人知识库的扩展

10.1 为什么个人知识库要面向“检索复用”而不是“堆存笔记”

近一年里，Andrej Karpathy 关于 LLM Wiki 的讨论受到很多开发者关注。核心思想是：把知识以结构化文本形式保存下来，让 LLM 在回答问题时基于已有笔记进行引用和推理，而不是每次都从零生成。

这个思想正好解决研究场景的痛点。研究笔记不是收藏夹，不是摘抄本，而是用来支撑下一次研究和下一次写作的素材库。笔记的价值取决于它被检索和复用的效率。

10.2 从“论文笔记”到“实验日志”到“错误归档”的扩展

个人知识库可以按数据类型划分成几个区域：

论文笔记：每篇论文一个 Markdown 文件，记录问题、方法、实验、局限。
实验日志：每次实验记录配置、指标、结论和可视化图。
错误归档：遇到的报错、原因、解决方式、预防建议。
代码片段：常用脚本、模板、prompt 模板、RAG 上游处理流程。

把这些区域统一放入同一个向量库，后续一个新问题时，既可能检索到相关论文，也可能检索到之前踩过的坑。这种跨类型检索正是 RAG 相对传统文件夹搜索的优势。

10.3 不要盲目追求“全自动研究助手”

当前很多文章会展示一个看起来很智能的 Agent 流程：输入一个研究主题，Agent 自动去搜索论文、读 PDF、生成报告。这种全自动流程在演示时效果很好，但在真实研究中容易出问题。

原因在于，研究过程中的判断非常依赖领域知识，而 Agent 缺少两个关键能力：一是对不确定信息的识别和主动询问，二是对领域内默认知识的理解。全自动流程一旦在某一步检索到错误论文，后续所有步骤都会基于错误信息继续，最终输出的报告可能很完整，但核心结论是错的。

更稳妥的模式是“半自动”：LLM 负责处理结构化、批量、耗时的环节，人工负责关键的判断和决策。比如筛选候选论文时，LLM 可以生成结构化表格，但最终选哪 20 篇精读，仍然由人工决定。这不是保守，而是对研究质量负责。

11. 从零搭建一个“研究辅助 CLI”的完整示例

11.1 设计目标

把前面涉及的功能整合起来，可以做一个非常简单的研究辅助 CLI。它支持三个子命令：

search：用 arXiv API 搜索论文，并调用 LLM 输出结构化 JSON。
add-note：把一篇 Markdown 笔记写入知识库。
ask：从知识库检索并回答问题。

这样就把文献调研、知识沉淀、检索问答三个环节放到了一个统一工具里。

11.2 项目结构

research-cli/ main.py requirements.txt .env notes/ README.md

requirements.txt：

requests python-dotenv langchain langchain-community chromadb unstructured markdown

11.3 search 子命令实现

import argparse import json import urllib.parse import urllib.request import xml.etree.ElementTree as ET import requests ARXIV_API = "http://export.arxiv.org/api/query" def fetch_arxiv_papers(query: str, max_results: int = 10): params = { "search_query": f"all:{query}", "start": 0, "max_results": max_results } url = f"{ARXIV_API}?{urllib.parse.urlencode(params)}" with urllib.request.urlopen(url) as resp: data = resp.read().decode("utf-8") ns = {"atom": "http://www.w3.org/2005/Atom"} root = ET.fromstring(data) papers = [] for entry in root.findall("atom:entry", ns): title = entry.find("atom:title", ns).text.strip().replace("\n", " ") summary = entry.find("atom:summary", ns).text.strip().replace("\n", " ") link = entry.find("atom:id", ns).text papers.append({"title": title, "summary": summary, "url": link}) return papers def summarize_papers(papers, api_key, base_url, model): prompt = f"""请将以下论文列表整理为 JSON 数组。每项字段见说明。 要求只基于摘要，不补充外部知识。 {papers}""" resp = requests.post( f"{base_url}/chat/completions", headers={"Authorization": f"Bearer {api_key}"}, json={ "model": model, "messages": [{"role": "user", "content": prompt}], "temperature": 0.2 } ) return resp.json()["choices"][0]["message"]["content"] def main(): parser = argparse.ArgumentParser() parser.add_argument("--query", required=True) parser.add_argument("--max-results", type=int, default=10) args = parser.parse_args() papers = fetch_arxiv_papers(args.query, args.max_results) result = summarize_papers(papers, os.getenv("LLM_API_KEY"), os.getenv("LLM_BASE_URL"), os.getenv("LLM_MODEL")) print(result)

这段代码把第 3 节的核心逻辑合并成了一个可执行的脚本。实际使用可能需要调整 base_url 的路径规则，不同模型服务提供商的 /chat/completions 路径可能不同。

11.4 ask 子命令实现

def ask_question(question: str): from langchain_community.document_loaders import DirectoryLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import Chroma loader = DirectoryLoader("notes/", glob="**/*.md") docs = loader.load() splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50) chunks = splitter.split_documents(docs) embedding = HuggingFaceEmbeddings(model_name="BAAI/bge-small-zh-v1.5") vectorstore = Chroma.from_documents(chunks, embedding) retriever = vectorstore.as_retriever(search_kwargs={"k": 4}) retrived = retriever.get_relevant_documents(question) context = "\n\n".join([doc.page_content for doc in retrived]) prompt = f"""请仅根据以下资料回答问题。资料中没有的内容直接说“资料中没有相关内容”。 资料： {context} 问题：{question}""" resp = requests.post( f"{config['base_url']}/chat/completions", headers={"Authorization": f"Bearer {config['api_key']}"}, json={ "model": config["model"], "messages": [{"role": "user", "content": prompt}], "temperature": 0.1 } ) answer = resp.json()["choices"][0]["message"]["content"] print("回答：", answer) print("参考片段：") for i, doc in enumerate(retrived): print(f"[{i+1}] {doc.page_content[:200]}")

注意 ask 命令每次运行时都会重新构建向量库，个人笔记量小时没问题。笔记量增大后，应改成向量库持久化加增量更新，否则每次提问都要重新 embedding，耗时太长。

12. 常见问题排查：从“回答不对”反推原因

12.1 排查顺序优先级

使用 LLM 做研究辅助时，遇到“回答不对”或“效果差”，建议按以下顺序排查：

问题是否清晰。提问是否明确指定了输入范围、输出格式和不能做的事。
输入材料是否正确。是让模型读摘要还是读全文，分块有没有截断关键信息。
模型参数是否合适。temperature 是否过高，max_tokens 是否截断，top_p 是否异常。
提示词是否约束了范围。是否允许模型补充外部知识，是否允许自由发挥。
知识库检索是否命中。RAG 场景中，先检查检索到的片段是否相关，再检查 LLM 回答。
输出解析是否失败。JSON 输出是否有额外文字，是否有转义问题。
模型版本和 API 行为是否稳定。相同参数下结果差异是否影响判断。

12.2 常见问题表

问题现象	可能原因	检查方式	处理建议
LLM 推荐了不存在的论文	模型在自由生成引用	用搜索引擎验证论文是否存在	更换流程：先检索真实论文，再让 LLM 整理
结构化 JSON 输出不稳定	prompt 未严格要求 JSON	查看原始响应	在输出前加“只输出 JSON”，并使用解析兜底
摘要结果过于泛泛	输入是全文，模型抓不住重点	检查输入长度和切分	按章节输入，每章节单独提问
RAG 回答与笔记无关	检索片段不相关	打印检索片段	调整分块大小或换 embedding 模型
运行两次结果不同	temperature 设置过高或模型非确定性	固定参数复测	temperature 调低，记录模型版本和参数
本地模型回答质量差	模型参数规模小	对比云端模型	本地模型做批量任务，复杂推理用云端
API 调用超时	输入过长或模型推理慢	检查日志耗时	加超时重试，必要时减少输入长度
实验结果代码无法运行	生成代码缺少真实路径或依赖	检查代码细节	人工审查代码后再运行，不能直接提交 GPU 任务

12.3 排查时最容易被忽略的环节

很多人先怀疑模型能力，但真实原因经常在更简单的地方：输入材料本身有问题。比如把网页复制进 prompt 时带了大量无关导航文字；比如 OCR 论文时公式被识别错误；比如从 PDF 提取的文本丢失了表格结构。

所以排查的第一步不是换更强的模型，而是检查输入文本。先把输入打印出来，人工看一眼，确认模型收到的内容确实是研究中需要的内容。

13. 最佳实践：把 LLM 当成研究团队里的“初级研究员”来管理

13.1 明确职责边界

可以把 LLM 当成一个效率很高但需要监督的初级研究员，给它分配任务时，明确三点：输入是什么、输出格式是什么、哪些事情绝对不要做。

比如分配文献筛选任务时，明确：

输入：arXiv API 返回的 10 篇论文标题和摘要。 输出：JSON 数组，包含标题、方法、数据集、结论、局限。 不要做：不要给论文打分排序，不要推荐额外论文，不要生成引用条目。

13.2 建立 prompt 模板版本库

研究项目中，提示词本身是需要版本管理的资产。建议把常用 prompt 存成文件，纳入 git 管理，每次修改记录版本号。例如：

prompts/ literature_review_v1.md paper_explainer_v1.md paper_explainer_v2.md code_debug_v1.md rag_answer_v1.md

这样当问题复现时，可以定位到“当时的 prompt 和现在的 prompt 差别在哪里”，而不是凭记忆猜测。

13.3 明确人工复核点

研究流程中，至少要设置以下人工复核点：

文献筛选结果，人工确认最终纳入精读的论文列表
从论文段落中提取的 Method 描述，人工确认与原文一致
LLM 生成的实验代码，人工 review 后再运行
润色后的论文段落，人工逐句检查是否改变原意
任何引用文献，必须回到原始来源确认

如果这些复核点被跳过，LLM 就从一个辅助工具变成了黑盒决策器，这在研究里是危险的。

13.4 面向长期维护的建议

长期使用 LLM 做研究，还要注意三点：

第一，关注新模型和新技术，但不要频繁切换。每次切换模型都要重新跑一遍小型评估集，确认没有引入新的质量回退。

第二，注意 Token 成本。批量处理大量文本时，先在小样本上验证质量和成本，再全量执行，避免一次任务烧掉大量额度。

第三，做好原始数据备份。LLM 的摘要、整理、结构化输出都是派生数据，原始论文和原始实验记录必须单独保存，不能只依赖模型输出。

14. 推荐的学习路径与下一步实践方向

如果刚接触 LLM 辅助研究，我的建议是按下面的顺序推进：

第一阶段：直接使用对话式 LLM 阅读论文，但每次提问都要求模型给出结构和约束，比如“基于这段摘要，使用 JSON 输出论文方法、数据集、局限”。

第二阶段：搭建本地环境，用 Ollama 或 API 完成批量文献摘要，把所有结果保存为结构化笔记。

第三阶段：引入 RAG 知识库，把论文笔记、实验日志和代码片段统一检索，养成“回答必带参考”的习惯。

第四阶段：为一个具体研究主题搭建“检索 + 摘要 + 问答 + 写作辅助”的完整工作流，并用小型评估集持续监控质量。

再往后，可以探索更复杂的 Agent 场景，比如把论文检索、实验代码生成、结果报告整合成一个半自动流程。但每一步都要明确人工智能的边界和人工复核点，否则工具越复杂，错误越难发现。

真正有价值的研究工具，不是那些看起来“全自动”的系统，而是能让人在更短时间里做出更好判断的系统。LLM 在这条路上的最大贡献，是帮研究者从繁琐的文献处理、代码调试和文本润色中解放出来，把注意力放回到科学问题本身。