从“提问”到“工作流”我用 LLM 做技术研究的完整实践如果你平时看 Hacker News大概率见过“Ask HN: How do you use LLMs for your research?”这类帖子。很多人以为回答里会是各种炫酷的 Agent 编排、自动化流水线但点进去你会发现真正高频、真正被研究者依赖的用法往往朴素得多让 LLM 通读 PDF、整理文献脉络、帮忙把一段晦涩代码翻译成可理解的逻辑、在空白文档前当一块“思维跳板”。这篇文章不打算复述某个 HN 帖子的回复而是想结合我自己的实践把“用 LLM 做研究”这件事拆成一条可落地的技术路径从论文阅读、知识库构建到 Agent 化文献调研再到精度选择这类容易被忽略的底层细节。读完你可以直接照着搭一套自己的研究辅助系统而不是停留在“问两句 ChatGPT”的层面。先说一个明确判断LLM 在研究场景里真正改变的不是“帮你写论文”而是把“读文献—理脉络—找 gap—做实验—写总结”这条长链路里的重复劳动压缩掉。它能帮你快速建立对陌生领域的整体认知但它不能替你验证事实更不能替你思考。理解这一点比学会任何工具都重要。1. 这篇文章真正要解决的问题先看一个典型场景。假设你刚进入一个新研究方向比如“基于大模型的 Agent 记忆机制”。第一天你需要做什么大概率是打开 Google Scholar下载 20 篇论文然后一篇一篇读摘要、看方法、对比实验。这个过程极其耗时而且有一个很隐蔽的问题你的注意力会被单篇论文带走很难快速形成领域地图。传统做法是什么建一个文件夹按主题分类手动维护 Excel 表格记录每篇论文的贡献、方法、局限。这个做法不是不行但它存在三个问题第一文献之间的关联关系很难用表格表达。第二读过的论文过两周就忘需要反复回看。第三从“读完文献”到“形成自己的研究思路”之间缺少一个高效的中间加工环节。LLM 恰好能在这三个位置提供帮助。它可以作为文献预处理器、知识组织器和思路生成器。但这并不是说“装一个 ChatGPT 插件就完事了”而是需要设计一套工作流让 LLM 在合适的位置介入同时把准确性问题控制在可接受范围内。这篇文章会覆盖以下几件事研究场景中 LLM 的核心能力边界一篇论文从 PDF 到知识库的完整处理流程如何用 RAG 和本地知识库管理文献如何用 Agent 做半自动文献调研以及一个容易被忽略但非常关键的话题——LLM 的数值精度选择fp16、fp32、bf16对研究任务的影响。2. 研究场景中的 LLM能力边界与常见误区在动手搭建工具链之前先明确 LLM 在研究流程里到底能做什么、不能做什么。这个判断会影响你后续所有的技术选型。2.1 能做的信息压缩与结构提取LLM 最擅长的一件事是把高密度信息压缩成结构化表达。一篇论文的 Introduction 可能有两页但你真正需要记住的可能是三句话这篇论文解决什么问题、方法核心是什么、跟之前工作相比差异在哪。把这种压缩工作交给 LLM能节省大量阅读时间。同样LLM 可以用来提取论文里的关键信息比如研究问题、方法框架、数据集、评测指标、局限与未来工作。把这些字段提取出来你就得到了一个结构化的文献数据库后面可以按主题检索、按时间排序、按方法聚类。这个能力的技术基础是 LLM 的上下文理解与指令跟随能力。你不需要微调模型只需要设计好提示词让模型按照固定格式输出。这也是为什么“提示词工程”在研究场景里仍然有实用价值——它不是花哨的套路而是给模型提供稳定的输出协议。2.2 不能做的事实验证与逻辑推演LLM 最不可靠的地方是它可能一本正经地生成错误内容。在研究场景里这会造成严重问题如果你让 LLM 总结某篇论文的方法它可能会把另一个模型的名称混进来如果你让它对比两篇论文的差异它可能会编造不存在的实验数据。所以我的原则是LLM 负责“初筛”和“组织”人负责“验证”和“决策”。所有 LLM 输出的摘要、对比、结论都必须能回溯到原始文献。这也是为什么我们后面要强调 RAG 和引用溯源而不是简单地把问题扔给一个在线聊天机器人。2.3 核心误解LLM 不等于搜索很多人把 LLM 当成搜索引擎用问“这个领域有哪些重要论文”。这其实是个误区。LLM 的训练数据有截止时间它不可能知道最新的研究成果同时它也无法保证它提到的论文是真实存在的。真正做研究时论文的检索应该交给学术搜索引擎LLM 只负责对已检索到的内容做深度加工。一句话总结LLM 是研究流水线上的“加工中心”不是“原料供应商”。原料必须来自真实的学术数据库加工过程则可以用 LLM 大幅提效。3. 底层细节精度选择为什么影响研究结果如果你只是用在线 API可能从来不需要关心精度问题。但如果你想在本地跑一个开源模型来处理文献或者自己微调一个模型来提取论文信息那你一定会遇到一个选择用 fp16、fp32 还是 bf16这不是一个可以随便选的参数它直接关系到你能用多大的模型、以多快的速度推理以及最关键的一点——输出质量是否稳定。3.1 fp32最稳定但最占资源fp32 是单精度浮点数用 32 位表示一个数。它是深度学习的“标准”精度训练时通常默认使用。优点是数值范围大、精度高模型权重更新时不容易出问题缺点是显存占用高、计算速度相对慢。如果你在消费级显卡上跑 7B、13B 这样的模型fp32 往往会显存不够。举例来说一个 7B 参数的模型权重就要占 28GB 显存已经接近很多高端显卡的上限了。所以 fp32 通常只在训练或微调时作为“基准精度”使用推理时很少直接用。3.2 fp16速度快但容易溢出fp16 是半精度浮点数用 16 位表示一个数。它的优点是显存占用减半、计算速度更快所以很多推理框架默认支持 fp16。但 fp16 有一个明显问题它的动态范围比 fp32 小得多当数值非常小或非常大时容易发生上溢或下溢。在推理场景中fp16 通常表现良好但如果你在处理长文本、复杂推理任务时某些中间计算结果可能超出 fp16 的范围导致输出质量下降。这种问题比较隐蔽因为你可能只看到模型输出变差了但不会想到是精度问题。3.3 bf16训练和推理的好选择bf16 是“脑浮点数”由 Google 提出。它的指数范围和 fp32 完全一致只是尾数精度较低。这意味着 bf16 能表示和 fp32 一样大的数值范围不容易溢出只是精度略低。对于 LLM 来说bf16 是目前训练的主流选择也是很多 GPU尤其是 A100、H100 等的原生支持格式。如果你在本地用新一点的显卡跑模型优先尝试 bf16。3.4 研究场景中的实践建议那做研究时到底选哪个我的建议分情况纯推理、追求速度优先 fp16如果发现输出质量异常再对比 bf16。纯推理、追求稳定性优先 bf16显存允许时用 fp16两者差不多。微调模型如果硬件支持用 bf16如果不支持用 fp16 梯度缩放。显存紧张用量化版本比如 4bit 或 8bit但要注意量化对长文本综合分析任务的影响。还有一个更实用的建议跑某一批文献提取任务时先用相同提示词、不同精度各跑一遍对比输出结果。如果关键字段完全一致说明精度不是瓶颈如果差异很大就要考虑用更高精度或调整提示词。这种“精度对照测试”在研究工作流里非常推荐。4. 研究辅助工具链从在线服务到本地部署研究场景里工具链的选择会直接影响工作效率。这里没有唯一正确答案但你要清楚不同方案的边界。4.1 在线 API 方案如果你不关心数据隐私、预算充足直接用在线 API 是最快的。主流选项包括 OpenAI 的 GPT 系列、Anthropic 的 Claude 系列、Google 的 Gemini 系列以及国内的各类大模型 API。这类方案的好处是免部署、模型能力强、上下文窗口大。适合的场景快速阅读论文、生成初稿、头脑风暴。缺点也很明显每百万 token 的成本会随着使用量上升而且论文内容可能涉及未公开的研究数据需要评估合规风险。4.2 本地模型方案如果你担心数据安全或者想深入研究模型行为本地部署是更好的选择。常见的开源模型包括 Llama 3、Qwen、DeepSeek 等。配合 Ollama、llama.cpp、vLLM 等推理框架可以在消费级硬件上运行 7B 到 14B 的模型。本地方案里我比较推荐先试 Ollama因为它的安装和命令行交互非常简洁几行命令就能跑起一个模型。后续如果需要更高吞吐量再迁移到 vLLM。4.3 LLM wiki 范式与本地知识库近年来“LLM wiki”这个概念越来越热。它最早可以追溯到 Andrej Karpathy 提出的一个观点不要只把 LLM 当成对话工具应该把个人笔记、知识库和 LLM 结合起来构建一个“你专属的 wiki”。也就是说你把自己读过的论文、写过的笔记、整理过的代码片段都放到一个本地知识库里然后让 LLM 基于这个知识库回答你的问题。这个范式落到研究场景就是用 Obsidian 或普通 Markdown 文件夹维护论文笔记用向量数据库做 embedding 索引然后通过 RAG 让 LLM 基于你的笔记回答问题。相比直接问通用 LLM这种方式的答案更贴合你自己的研究上下文而且能追溯到原始来源。4.4 搭建工具链的判断标准搭建工具链时不要被“最新工具”带偏。判断标准只有三条第一它是否融入了你已有的工作流第二它是否可脚本化、可自动化第三它是否允许你导出数据避免被单一工具锁定。研究是一个长期过程工具链的稳定性和可迁移性可能比“功能更多”更重要。5. 核心流程拆解一篇论文如何进入你的知识库下面我以一个具体的例子拆解从“下载 PDF 论文”到“知识库可检索”的完整流程。这个流程按顺序分为五个步骤文本抽取、内容切分、向量化、存储索引、交互问答。每一步都有明确的目标和常见的坑。5.1 文本抽取PDF 转纯文本第一步是把 PDF 论文转成纯文本或 Markdown。这里有两个层次一是直接抽取文字适合以文本为主的论文二是解析版式保留标题、段落、表格结构适合排版复杂的双栏论文。推荐的工具包括pymupdf轻量快速、pdfplumber表格抽取强、marker高质量 PDF 转 Markdown、minerU学术 PDF 解析。我的建议是先用pymupdf跑一遍如果遇到扫描版或复杂公式再用更强力的工具。抽取之后要人工抽查一下质量。很多 PDF 的公式、上下标会变成乱码这些内容在后面对话中会被 LLM 误解。一个技巧是把抽取结果保存为 Markdown用编辑器打开快速过一遍。5.2 内容切分不是简单按字符数切很多初学者在这里会犯一个错误按固定字符数硬切文本。这样做的后果是一个完整段落会被切到两个 chunk 里导致检索时上下文不完整。更合理的策略是按语义边界切分。比如优先按 Markdown 标题切标题太长再按段落切段落太长再按句子边界切。具体 chunk 大小取决于你的 embedding 模型和 LLM 上下文窗口一般 500 到 1000 token 是一个比较稳妥的范围。5.3 向量化选择 embedding 模型接下来把每个 chunk 转成向量。这里选择的 embedding 模型会直接决定检索效果。中文论文用bge-m3或text2vec系列表现不错英文论文可以用OpenAI text-embedding-3-small或者本地的BAAI/bge-large-en-v1.5。需要注意一点embedding 模型是“按句/按段”编码的它对语义相似度敏感但对“关键词精确匹配”反而可能不如 BM25。所以很多 RAG 系统会做“混合检索”把向量检索和关键词检索的结果融合起来。研究场景里论文标题、作者名、方法名的精确匹配经常很重要建议加入 BM25。5.4 存储索引使用向量数据库向量存储的选择很多从轻量的chroma、lancedb到生产级的milvus、qdrant。我的建议是个人研究用chroma就够了它支持本地持久化API 简单没什么学习成本。如果你希望把文献管理做得更像一个数据库可以用lancedb它基于 Lance 格式支持多模态和复杂的过滤查询。但不要在一开始就纠结数据库选型先用最简单的方案把流程跑通后面再替换。5.5 交互问答构建 RAG 查询最后一步是把用户的问题转成向量在向量库里检索最相关的 chunks然后拼进提示词让 LLM 基于这些 chunks 回答。这里的关键是提示词里的“引用约束”提示词要明确告诉模型“只基于下面提供的资料回答如果资料里没有相关信息直接说‘资料中未提及’不要自行补充。”这一步是防止 LLM 幻觉的关键。很多人在 RAG 系统里仍然看到幻觉就是因为提示词里没有加硬性约束。6. 完整示例用 LangChain 构建论文知识库下面我们用一个最小可运行的示例把上述流程串起来。示例使用 Python LangChain Chroma Ollama 本地模型这样不需要额外申请 API key 就能跑通。如果你更习惯在线 API也可以把 Embedding 和 LLM 的初始化部分替换成 OpenAI 等服务的封装。6.1 环境安装pip install langchain langchain-community chromadb pymupdf如果要在本地跑 LLM先安装 Ollamacurl -fsSL https://ollama.com/install.sh | sh ollama pull qwen2.5:7b ollama pull bge-m3这里选择bge-m3作为 embedding 模型是因为它对中英文都支持得比较好也是很多本地知识库项目的默认选择。qwen2.5:7b作为生成模型在消费级显卡上性能尚可。6.2 读取 PDF 并切分# 文件路径research_kb/ingest.py import fitz from langchain.text_splitter import MarkdownHeaderTextSplitter def extract_pdf_text(pdf_path: str) - str: doc fitz.open(pdf_path) pages [] for page in doc: pages.append(page.get_text(text)) return \n.join(pages) # 简单按段落切分实际场景建议用 MarkdownHeaderTextSplitter def split_text(text: str, chunk_size: int 800, chunk_overlap: int 100): from langchain.text_splitter import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_sizechunk_size, chunk_overlapchunk_overlap, separators[\n\n, \n, 。, , , , ], ) return splitter.split_text(text)这是一个非常基础的切分逻辑。如果你要处理的是高质量论文库建议先用marker把 PDF 转成 Markdown再用 MarkdownHeaderTextSplitter 按标题层级切分。这里的实现足够演示流程。6.3 写入向量库# 文件路径research_kb/build_index.py from langchain_community.vectorstores import Chroma from langchain_community.embeddings import OllamaEmbeddings embeddings OllamaEmbeddings(modelbge-m3) def build_index(texts, persist_dir: str ./chroma_db): vectorstore Chroma.from_texts( textstexts, embeddingembeddings, persist_directorypersist_dir, ) return vectorstoreChroma 默认会把索引持久化到本地目录重启后不需要重新构建。注意OllamaEmbeddings需要本地 Ollama 服务正在运行。6.4 基于检索的问答# 文件路径research_kb/ask.py from langchain_community.vectorstores import Chroma from langchain_community.embeddings import OllamaEmbeddings from langchain_community.chat_models import ChatOllama from langchain.chains import RetrievalQA from langchain.prompts import PromptTemplate embeddings OllamaEmbeddings(modelbge-m3) vectorstore Chroma( persist_directory./chroma_db, embedding_functionembeddings, ) llm ChatOllama(modelqwen2.5:7b, temperature0) template 请仅根据以下资料回答问题。 如果资料中找不到答案请回答“资料中未提及”不要自行推断。 资料 {context} 问题 {question} 回答 prompt PromptTemplate(templatetemplate, input_variables[context, question]) qa_chain RetrievalQA.from_chain_type( llmllm, retrievervectorstore.as_retriever(search_kwargs{k: 4}), chain_typestuff, chain_type_kwargs{prompt: prompt}, ) result qa_chain.invoke(这篇论文提出的方法在哪些数据集上做了评测) print(result[result])这段代码的思路是先用向量库召回最相关的 4 个文本块再把这 4 个文本块拼入提示词让 LLM 只根据这些文本回答。temperature0是为了让输出更稳定、更接近资料原文。6.5 运行与验证把论文 PDF 放到papers/目录然后依次运行python ingest.py python build_index.py python ask.py如果一切正常你应该能看到类似输出模型从你的知识库中提取出数据集名称而不是凭空猜测。验证成功的标志有两个回答内容能在原始 PDF 中找到对应位置当问题超出知识库范围时模型能回答“资料中未提及”。7. 进阶用 Agent 做半自动文献调研RAG 能回答“这篇论文讲了什么”但研究场景还有更复杂的任务比如“找出这个领域最近一年提出的三类记忆机制并对比它们的差异”。这类任务需要多步推理而且可能需要多次检索。这时候就可以引入 Agent。7.1 Agent 的最小工作方式研究场景里的 Agent不一定要像科幻电影里那样复杂。一个最小可用的 Agent 就是“循环”拆解任务 - 检索知识库 - 生成中间结论 - 判断是否需要继续检索 - 最终回答。具体到代码你可以用 LangChain 的create_retriever_agent来实现。它本质上是一个 ReAct 模式的 Agent模型先决定调用哪个工具比如搜索向量库看完结果后再决定下一步动作。# 文件路径research_kb/agent_demo.py from langchain.agents import create_retriever_agent, AgentExecutor from langchain.agents.agent_toolkits import create_retriever_tool from langchain_community.vectorstores import Chroma from langchain_community.embeddings import OllamaEmbeddings from langchain_community.chat_models import ChatOllama embeddings OllamaEmbeddings(modelbge-m3) vectorstore Chroma( persist_directory./chroma_db, embedding_functionembeddings, ) retriever vectorstore.as_retriever(search_kwargs{k: 6}) tool create_retriever_tool( retriever, namesearch_papers, description在本地论文知识库中检索学术文献内容, ) llm ChatOllama(modelqwen2.5:7b, temperature0) agent create_retriever_agent(llm, [tool], verboseTrue) executor AgentExecutor(agentagent, tools[tool], verboseTrue) result executor.invoke({ input: 比较知识库中提到的三种记忆机制的优缺点并说明各自适用的场景。 }) print(result[output])这段代码是 LangChain 比较新的 API 写法。如果你安装的是旧版本接口可能略有差异你需要根据实际版本来调整。7.2 Agent 在研究场景中的注意事项Agent 看起来自动化程度很高但在研究场景里要谨慎使用。它有两个风险第一多步推理链条中任何一步如果检索到了不相关内容后续答案会被带偏第二Agent 可能过度依赖上下文忽略了你没有提供但很重要的事实。所以我建议把 Agent 定位为“半自动”。你可以让 Agent 生成一份调研草稿但最终一定要回到原始文献确认。与其追求全自动不如把 Agent 当作一个能快速调用工具、组织信息的助手。8. 常见问题与排查思路在实际使用这套工作流时你大概率会遇到下面这些问题。我整理了一个排查表问题现象可能原因排查方式解决方案Ollama 模型加载慢本地显存不足模型被迫用 CPU 推理查看ollama ps和显卡占用换小模型如 3B/4B或增加 swap 空间检索结果不相关切分粒度太大或太小打印每个 chunk 的开头查看语义完整性调整 chunk_size 和 overlap按标题切分LLM 回答与资料不符提示词缺少约束检查 Prompt 中是否有“仅根据资料回答”在提示词中加硬性约束并设置 temperature0PDF 抽取后公式乱码PDF 公式是特殊字体编码抽查抽取文本使用 marker 或 PDF 转 Markdown 工具同一个问题两次回答不一致模型 temperature 过高查看模型参数降低 temperature关闭采样随机性bf16 模型输出异常本地 GPU 不支持 bf16查看硬件文档改用 fp16或升级驱动向量库构建时间过长论文数量大、embedding 模型较慢查看批处理日志使用 GPU embedding或增大 batch size每个问题单独出现时都不难解决难的是它们交织在一起。我的经验是遇到问题时先固定变量。比如先检查“资料检索是否命中”再检查“模型是否按提示词执行”最后检查“是不是精度问题”。不要一开始就调模型那样只会让问题更复杂。9. 最佳实践与工程建议工作流跑通之后你会开始思考怎么让它更稳定、更长期可用。这里分享几条工程建议。9.1 给每一篇论文建立唯一 ID不要用文件名作为数据库主键因为文件名可能重复或修改。建议用论文的 DOI 或哈希值作为唯一 ID。这样可以避免重复导入同一篇论文也可以在你手动修改笔记时保持关联。9.2 分层维护元数据把论文的元数据标题、作者、年份、期刊、DOI和正文内容分开存储。元数据用 SQLite 或 CSV 管理正文用向量库管理。这样你可以快速做筛选而不必每次都走向量检索。9.3 定期做导出备份无论你用什么向量数据库都要定期导出原始文本和元数据。原因很简单向量库可能因为版本升级而无法读取。更稳妥的方案是“文件即真理”Markdown 笔记是源头向量库只是索引。索引丢了可以重建源文件丢了就真的没了。9.4 设计可复用的提示词模板研究场景里你会反复用到几种提示词论文摘要、方法对比、局限性分析、实验设计建议。建议把这些提示词保存为独立的模板文件并在提示词里预留固定的变量名。这样你更换模型时不需要重写所有调用代码。9.5 关注数据合规如果你处理的数据涉及未公开的研究成果或用户隐私不要直接上传到公有 API。可以考虑本地模型、私有化部署或使用支持数据隔离的云服务。这个提醒不是多余的很多研究团队在初期没有建立这个意识后期处理起来非常被动。9.6 建立人工抽检机制建议每周抽检 10% 的 LLM 输出回到原始文献核对。这能及时发现模型漂移或知识库污染问题。研究质量是长期积累的结果如果初期不把关错误的信息可能被后续工作流放大最后影响你的研究结论。10. 总结把 LLM 变成研究基础设施而不是临时玩具回到开头的问题如何用 LLM 做研究答案不是找一个“最强大的模型”而是设计一套适合自己的工作流。LLM 真正能帮你节省的是文献阅读的初筛时间、知识整理的重复劳动和写作起笔的空白恐惧。但它无法替代的是检索原始文献时的判断力、验证实验数据的严谨性和提出研究问题的洞察力。一个更稳妥的判断是未来几年LLM 会用研究者的个人知识库深度绑定。那种“问一句、信一句”的用法会越来越少取而代之的是像“LLM wiki”这样的范式——你的笔记、你的文献、你的代码片段共同构成一个私人可检索的研究基础设施。模型会换工具会变但这个基础设施的积累价值会一直增长。如果你现在正准备开始搭建自己的研究辅助系统我的建议是从最小闭环做起先处理 5 篇论文跑通“PDF - 文本 - 向量库 - 问答”这条链路再慢慢扩展。不要一开始就追求复杂 Agent 和自动化因为工具的复杂度一旦超过你的维护能力它就会从助手变成负担。最后提醒一句LLM 输出的内容永远要当作“待核实的草稿”而不是“可引用的事实”。保持这个习惯你就能既享受效率提升又不被模型的幻觉带偏。