很多做研究、写技术方案的朋友最近都在问同一个问题大家都在说用 LLM 辅助研究到底是怎么用的是真能提升效率还是只是拿它当一个高级一点的搜索引擎我自己的体会是如果把 LLM 当成聊天窗口里的问答机器人那它对研究的帮助非常有限。但如果你围绕它设计一套完整的工作流——从文献阅读、知识整理、检索问答到代码实验——它就能成为一个真正的研究助手。这篇文章我会结合近期实践完整梳理 LLM 在研究场景中的使用模式、背后的关键技术RAG、Agent、LLM Wiki 范式、模型精度并给出一套可以直接落地的知识库搭建方案。1. 从“聊天”到“研究”LLM 在研究中的角色定位1.1 LLM 研究助手的四个层次LLM 在科研和技术研究中的使用我把它分成四个层次你可以对照一下自己目前处于哪个阶段。第一层是信息检索辅助。把 LLM 当作高级搜索引擎问它某个概念是什么、某个算法怎么理解、某篇论文的核心贡献是什么。这一层最基础也是大多数人正在用的。它的优点是快缺点是回答可能不准确、不全面而且没有和你自己的知识体系产生连接。第二层是文献阅读与信息抽取。研究者每天面对大量论文、技术文档LLM 可以帮你做摘要、提取关键方法、对比多篇论文的异同、整理术语表。这一层开始有工作流的概念了不再是一次性问答而是批量处理。第三层是知识库构建与语义检索。这是目前研究场景中最实用的一层。你把读过的文献、笔记、实验记录统一存到一个知识库中用向量化Embedding的方式建立索引然后让 LLM 在检索到的内容基础上回答问题。这就是所谓的 RAGRetrieval-Augmented Generation检索增强生成架构也是 LLM Wiki 范式的核心。第四层是Agent 自动化研究流程。LLM 不再只是回答问题而是通过 Agent 编排工具自动执行“查文献→读摘要→提取关键信息→存入知识库→生成综述初稿”这类完整流程。这一层对工程能力要求较高但也是研究效率提升最明显的阶段。1.2 为什么研究场景需要专门的工作流直接和 ChatGPT 对话做研究最大的问题有三个。第一个是上下文窗口限制。一篇论文动辄几十页你很难把完整内容都塞进对话里。即使模型支持超长上下文成本和时间开销也很大。第二个是知识时效性。模型训练数据有截止日期你研究的最新论文、最新技术报告它没见过。你需要把外部资料喂给它。第三个是回答可复现性。同样是问“这个方向有哪些值得关注的工作”你每次得到的回答可能都不一样而且模型可能编造不存在的文献。这对研究来说是致命的。所以真正适合研究场景的 LLM 使用方式一定不是“在一个对话框里问所有问题”而是“让 LLM 嵌入到一个可检索、可追溯、可验证的知识管理系统中”。这也是行话里说的LLM Wiki 范式的由来。所谓 LLM Wiki是 Andrej Karpathy 提出的一种知识库使用范式你维护一个纯文本的、结构化的知识库类似 WikiLLM 作为这个知识库的查询接口和内容生成工具。它的核心优势在于知识在人可读的 Markdown 文件中沉淀LLM 负责检索、索引、总结和问答两者各司其职。这样既保留了原始资料的准确性又获得了 LLM 的自然语言交互能力。2. 研究场景的 LLM 使用模式盘点2.1 文献阅读与信息抽取文献阅读是研究中最耗时也最值得用 LLM 提效的环节。常见的使用模式有论文速读把论文 PDF 转成文本用 LLM 生成结构化摘要研究问题、方法、数据集、实验结果、局限性。多篇对比让 LLM 对比几篇相关工作的方法差异和实验设置差异。术语解释对论文中不熟悉的概念做即时解释比翻教科书快得多。公式说明让 LLM 用自然语言解释论文中的关键公式含义帮助理解推导过程。这里有一个容易被忽略的细节很多研究者直接把 PDF 内容复制粘贴给 LLM这会导致格式混乱、公式丢失、引用信息错乱。更好的方式是使用专门的 PDF 解析工具比如pymupdf4llm把 PDF 转成结构化的 Markdown再交给 LLM 处理。2.2 知识库构建LLM Wiki 范式LLM Wiki 范式的核心思想是知识应该以纯文本形式沉淀而不是停留在对话记录里。具体做法是为每个研究主题建立一个 Markdown 文件或目录。文件内部使用统一的标题层级、标签、链接规范。用脚本或工具把 Markdown 文件批量向量化存入向量数据库。每次做文献阅读或研究时通过 LLM 生成的内容回写到知识库。提问时系统先从向量库检索相关内容再让 LLM 基于检索结果回答。这种模式解决了三个问题知识可积累、回答可溯源、内容可复用。你积累的知识库越庞大研究效率提升越明显。我自己常用的工具组合是 Obsidian 做知识库管理配合 Python 脚本做向量化索引再加上 LLM API 做问答。后面第 4 节会给出完整代码。2.3 写作与代码辅助LLM 在研究中的另一个重要用途是写作和代码辅助包括论文改写与润色把初稿中的中式表达改写为更地道的学术表达。代码解释与 Debug对一个函数做逐行解释或让 LLM 根据报错信息定位问题。实验脚本生成根据论文中的方法描述生成数据预处理的样板代码或模型训练骨架。LaTeX 辅助帮忙写公式、排版表格、生成参考文献格式。需要提醒的是LLM 生成的代码和写作内容一定要人工复核尤其是涉及实验数据、统计结果和引用文献的部分错误率并不低。2.4 推理启发与实验设计这一层是更高阶的用法。研究中经常遇到“卡壳”的情况某个问题怎么都绕不过去某个实验怎么设计都不合理。LLM 可以充当一个“思维碰撞对象”把你的实验设计描述给它让它列出潜在漏洞和改进方向。让它以不同视角审稿人、初学者、资深专家审视你的工作。让它生成一些“反直觉”的假设帮你拓展思路。这本质上是在利用 LLM 的生成式能力做头脑风暴而不是追求答案的准确性。从实际经验看这种用法虽然不常被提及但对研究思路的打开很有帮助。3. 核心概念拆解RAG、向量检索、Agent 与 MCP要真正把 LLM 用进研究场景有几个关键概念是绕不开的。理解了它们你就知道为什么直接用聊天窗口不够而需要一套完整的应用架构。3.1 RAG给 LLM 接上外部知识RAG 的全称是 Retrieval-Augmented Generation检索增强生成。它的思路很直接LLM 不知道的知识我们从外部知识库中检索出来拼接到提示词中让它基于这些内容生成回答。一个标准的 RAG 流程是将文档切分为段落或句子级别的片段。用 Embedding 模型把每个片段转换成向量。用户提问时把问题也转换成向量在向量库中做相似度检索。取回 Top-K 个最相关片段连同问题一起交给 LLM。LLM 基于检索片段生成回答并标注引用来源。RAG 对研究场景的价值在于你的知识库可以随时更新新增论文、笔记不需要重新训练模型回答是基于真实检索内容的可以追根溯源大大降低幻觉风险。3.2 向量检索与 EmbeddingEmbedding 是 RAG 的核心。简单说Embedding 就是把一段文本映射成一个高维向量语义相近的文本向量距离也近。做向量检索时把问题和文档都映射到同一个向量空间然后找距离最近的文档片段。研究场景中做向量化时有几个实际问题需要注意Embedding 模型的选择中文场景推荐使用支持中文的模型学术英文文献推荐用英文优化的向量模型。如果你的资料以中文为主选错模型会导致检索效果很差。向量数据库的选择小型个人知识库用chromadb或faiss就足够团队级别的知识库可以用milvus、elasticsearch等。文本切分策略切片大小直接影响检索效果。太大会导致检索不精确太小会丢失上下文。一般按段落或按固定长度例如 500 到 1000 字符切分并保留重叠区域。3.3 Agent 与 MCP让 LLM 从“回答问题”到“完成任务”RAG 让 LLM 能“知道更多”Agent 让 LLM 能“做更多”。Agent 的核心是让 LLM 作为“大脑”根据任务目标自主决定调用哪些工具、按什么顺序执行。在研究场景中Agent 可以做的事情包括调用搜索工具查找最新论文。调用 PDF 解析工具读取论文内容。调用代码执行工具跑一个简单的数据统计。调用数据库工具把整理好的内容写入知识库。而MCPModel Context Protocol模型上下文协议是让这些工具接入标准化的协议。有了 MCPLLM 应用可以用统一的方式接入各类外部工具和服务而不是为每个工具写一套自定义接口。用 MCP 配合 Agent可以把“查文献→整理→入库→生成综述”这类多步骤任务做成自动化管线。对于研究场景MCP 的实际意义在于你不用再把每个工具都单独接入一遍社区已经有很多现成的 MCP Server可以直接复用。比如接入 ArXiv 的 MCP Server、接入本地文件系统的 MCP Server、接入代码仓库的 MCP Server 等。3.4 LLM 应用为什么需要编排框架当你尝试把 RAG、Agent、MCP、向量库组合到一起时很快会发现直接用原生代码拼接各种组件链路一旦变长代码就变得难以维护。这个问题的解决方案是引入编排框架。常见的编排框架包括LangChain、LlamaIndex、Spring AI、Dify等。它们提供的核心能力是把 LLM 调用、向量检索、工具调用、记忆管理等模块统一管理。内置常用的提示词模板和链式调用逻辑。方便做日志追踪和效果调优。例如Spring AI是 Java 生态中比较有代表性的 LLM 应用编排框架。它和 Spring Boot 深度集成把ChatClient、EmbeddingModel、VectorStore等抽象成 Bean让 Java 开发者可以用统一的编程模型开发 LLM 应用。如果你所在的团队技术栈是 JavaSpring AI 是很适合研究落地的选择。后面第 4 节实战部分我会先用纯 Python 代码实现一遍核心逻辑这样更容易理解底层的运行原理。工程化落地时再考虑引入编排框架。4. 完整实战基于 LLM Wiki 范式搭建个人研究知识库这一节我们完整实现一个“文献知识库系统”把本地的 Markdown 研究笔记向量化建立索引然后通过命令行或 Web 界面做语义检索和问答。整体架构非常简单不依赖重型框架方便理解核心原理。4.1 整体架构系统的组成如下研究笔记Markdown 文件 ↓ 文档切分按标题段落拆分 ↓ 向量化Embedding API ↓ 存入向量数据库Chroma ↓ 检索问答先检索再让 LLM 生成回答用户只需要两样东西一个支持 Embedding 的模型服务线上 API 或本地模型以及一堆 Markdown 格式的研究笔记。4.2 环境准备本文示例以 Python 3.10 为基础需要安装以下依赖pip install chromadb openai markdown pymupdf4llm如果你使用的是本地模型例如通过 Ollama 启动模型则不需要安装openai库对应的线上 API Key改用兼容接口即可。需要说明的是具体版本以你安装时的最新稳定版为准本文重点是演示完整的配置思路版本差异不会影响核心逻辑。4.3 创建研究笔记目录结构建议在 Obsidian 或任意 Markdown 编辑器中创建如下目录结构research-wiki/ ├── notes/ │ ├── transformer.md │ ├── rag-introduction.md │ ├── llama-index-notes.md │ └── ... ├── scripts/ │ ├── build_index.py │ └── query.py └── vector_db/ # 向量数据库存储目录每一篇笔记内部建议遵循这样的格式规范--- title: Transformer 核心机制笔记 tags: [深度学习, NLP, Transformer] date: 2025-01-01 source: https://example.com/paper --- ## 核心概念 Transformer 完全基于注意力机制放弃了循环和卷积结构... ## 关键公式 Attention(Q, K, V) softmax(QK^T / sqrt(d_k)) V ## 与 RNN 的对比 | 特性 | RNN | Transformer | | --- | --- | --- | | 并行计算 | 不支持 | 支持 | | 长距离依赖 | 弱 | 强 | ## 我的思考 ...这种结构化规范的价值在于标题能作为语义切分的锚点元信息tags、source能帮助后续检索过滤。4.4 向量化与索引代码创建scripts/build_index.py代码如下# 文件路径scripts/build_index.py import os import re import glob import chromadb from chromadb.utils import embedding_functions # 配置向量数据库存储路径 DB_PATH ../vector_db NOTES_DIR ../notes COLLECTION_NAME research_wiki # 使用 OpenAI 兼容的 Embedding API # 可以替换为本地模型的兼容接口 embedding_func embedding_functions.OpenAIEmbeddingFunction( api_keyos.environ.get(OPENAI_API_KEY, your-api-key), model_nametext-embedding-3-small, ) # 初始化 Chroma 客户端 client chromadb.PersistentClient(pathDB_PATH) collection client.get_or_create_collection( nameCOLLECTION_NAME, embedding_functionembedding_func, ) def parse_markdown(file_path: str): 解析 Markdown 文件按标题拆分段落 with open(file_path, r, encodingutf-8) as f: content f.read() # 去掉 YAML front matter content re.sub(r^---\s*\n.*?\n---\s*\n, , content, flagsre.DOTALL) # 按二级标题拆分 sections re.split(r\n## , content) chunks [] sources [] for section in sections: section section.strip() if len(section) 50: continue chunks.append(## section) sources.append(file_path) return chunks, sources def main(): # 清空现有集合避免重复插入 existing collection.get() if existing[ids]: collection.delete(idsexisting[ids]) all_chunks [] all_sources [] all_ids [] md_files glob.glob(os.path.join(NOTES_DIR, *.md)) for idx, file_path in enumerate(md_files): chunks, sources parse_markdown(file_path) for i, (chunk, source) in enumerate(zip(chunks, sources)): all_chunks.append(chunk) all_sources.append(source) all_ids.append(fdoc_{idx}_chunk_{i}) collection.add( documentsall_chunks, idsall_ids, metadatas[{source: s} for s in all_sources], ) print(f索引完成共写入 {len(all_chunks)} 个片段) if __name__ __main__: main()运行命令cd scripts python build_index.py预期输出索引完成共写入 42 个片段这段代码的核心逻辑是读取 notes 目录下所有 Markdown 文件按二级标题拆分成语义片段然后向量化写入 Chroma 数据库。需要注意两点如果笔记格式统一拆分效果会很好如果你的笔记是自由文本建议先做格式化再入库。每次重建索引时会先清空旧数据这是为了避免重复插入。实际项目中可以按文件修改时间做增量更新。4.5 检索问答代码创建scripts/query.py代码如下# 文件路径scripts/query.py import os import chromadb from chromadb.utils import embedding_functions DB_PATH ../vector_db COLLECTION_NAME research_wiki TOP_K 5 # 同一个 Embedding 模型必须和建索引时一致 embedding_func embedding_functions.OpenAIEmbeddingFunction( api_keyos.environ.get(OPENAI_API_KEY, your-api-key), model_nametext-embedding-3-small, ) client chromadb.PersistentClient(pathDB_PATH) collection client.get_collection( nameCOLLECTION_NAME, embedding_functionembedding_func, ) def search(query: str, top_k: int TOP_K): 向量检索返回最相关的文档片段 results collection.query( query_texts[query], n_resultstop_k, include[documents, metadatas, distances], ) return results def generate_answer(query: str): 基于检索结果生成回答需要配置 LLM API results search(query) documents results[documents][0] sources results[metadatas][0] context \n\n---\n\n.join( [f[来源: {s[source]}]\n{d} for d, s in zip(documents, sources)] ) # 这里以 OpenAI 兼容接口示例本地模型可替换为 Ollama 等 from openai import OpenAI client OpenAI( base_urlos.environ.get(OPENAI_BASE_URL, https://api.openai.com/v1), api_keyos.environ.get(OPENAI_API_KEY, your-api-key), ) prompt f请基于以下检索到的研究笔记内容回答问题。 如果笔记中没有相关内容请直接说“知识库中没有找到相关资料”不要编造。 回答时请标注引用来源。 检索到的内容 {context} 问题{query} response client.chat.completions.create( modelos.environ.get(CHAT_MODEL, gpt-4o-mini), messages[ {role: system, content: 你是一个严谨的科研助手回答要简洁、准确、有依据。}, {role: user, content: prompt}, ], temperature0.2, ) return response.choices[0].message.content, documents, sources if __name__ __main__: import sys query sys.argv[1] if len(sys.argv) 1 else Transformer 的核心优势是什么 answer, docs, sources generate_answer(query) print( 回答 ) print(answer) print(\n 引用来源 ) for doc, src in zip(docs, sources): print(f- {src[source]})运行命令cd scripts python query.py Transformer 的核心优势是什么预期输出会包含两个部分基于知识库生成的回答以及引用来源的文件路径。整个流程是“检索增强生成”的最小实现。4.6 进阶接入 Agent 编排当你的知识库足够大、使用频率足够高之后可以引入LangChain或LlamaIndex做封装。下面是一个用LlamaIndex快速搭建的开源替代方案思路# 核心片段使用 LlamaIndex 封装知识库索引 from llama_index.core import VectorStoreIndex, SimpleDirectoryReader # 读取本地文档 documents SimpleDirectoryReader(../notes).load_data() # 构建索引底层仍然走 Embedding 与向量检索 index VectorStoreIndex.from_documents(documents) # 转为问答引擎 query_engine index.as_query_engine(similarity_top_k5) response query_engine.query(Transformer 的核心优势是什么) print(response)这段代码比手写 Chroma 更简洁适合快速原型验证。但在生产环境或研究项目需要精细控制检索逻辑时我更推荐你理解和掌握底层的 RAG 流程再决定是否依赖框架。5. 模型精度选择FP16、FP32、BF16 怎么选如果你在本地跑 LLM 或做推理实验经常会看到 FP16、FP32、BF16 这些词。它们指的是模型权重和计算时使用的浮点数精度格式直接关系到推理速度、显存占用和结果的准确性。5.1 为什么研究场景要关注精度研究者在以下两种场景下会强烈感知到精度的影响本地部署模型显存不够或推理太慢需要通过降低精度来换速度。但精度降低可能导致模型输出质量下降。实验对比不同精度下模型的输出可能有差异影响实验结果的可复现性。理解这三种精度格式的区别能帮你做出更合理的部署决策。5.2 三种精度格式的对比精度格式位数指数位尾数位特点FP3232 位8 位23 位标准精度训练时通常使用显存占用大推理速度慢FP1616 位5 位10 位半精度能加速推理、减少显存但数值范围小容易溢出BF1616 位8 位7 位脑浮点指数位与 FP32 相同范围大但精度低适合训练时混合精度简单理解FP32是最“准”的但资源消耗最大。FP16速度和显存都友好但小数值容易丢精度。BF16在数值范围上和 FP32 对齐不容易溢出但尾数精度更低。5.3 推理场景怎么选如果你的场景只是跑模型做文本生成、知识库问答推荐顺序是先尝试 FP16。绝大多数消费级显卡都能支持 FP16 推理显存减半速度提升明显质量损失通常可以接受。如果显存仍然不够尝试 INT8/INT4 量化比如bitsandbytes库。量化比 FP16 更激进但质量损失也更明显。如果你的任务对输出格式和数值要求极高例如数学推理、代码生成优先保留 FP16 或直接上 FP32。需要特别注意的是BF16 一般用于训练阶段的混合精度在 NVIDIA 的 V100、A100、H100 等显卡上有硬件加速。消费级显卡如 RTX 3060、4090 对 BF16 的支持要看驱动和框架版本不能想当然。如果只是为了推理而选择精度FP16 是最稳妥的起点。从实践角度看研究项目中最常遇到的问题是“同样的代码模型在不同精度下输出不一致”。解决方法是在实验记录中明确标注推理精度和模型版本保证对比实验在相同条件下进行。6. 常见问题与排查思路在研究场景中使用 LLM 工作流下面的问题几乎一定会遇到。问题现象常见原因解决思路调用 Embedding API 报错“文本向量 API 未配置”没有设置 API Key或环境变量读取不到检查环境变量是否生效确认 API 地址和密钥检索结果和问题完全不相关Embedding 模型选择不当或切片方式不合理换用更适合的 Embedding 模型调整切片大小检查文本清洗回答引用了知识库之外的内容提示词没有限制“只能基于检索内容回答”在提示词中明确约束降低 temperature 参数长文档被截断切片过短或切分逻辑丢失上下文使用带重叠的切片策略例如字符重叠 100-200本地模型推理速度很慢GPU 未启用或精度选择不合适确认 torch 是否使用 GPU尝试 FP16 或量化每次回答都不一样无法复现未固定随机种子temperature 过高设置环境变量和模型的随机种子调低 temperaturePDF 转文本后公式乱码PDF 解析工具选型不当使用 pymupdf4llm 等专用工具或手动校对关键公式下面挑几个典型的展开说明。6.1 文本向量 API 未配置的解决方法这个报错最常见于第一次运行索引脚本时。原因一般是代码中读取环境变量的逻辑写错了或者环境变量根本没设置。排查顺序如下确认是否在 shell 中设置了环境变量echo $OPENAI_API_KEY如果输出为空先设置环境变量再运行脚本export OPENAI_API_KEYsk-xxx确认 API 地址是否写对。如果你用的是本地模型例如 Ollama需要把base_url改成 Ollama 的地址例如http://localhost:11434/v1。如果使用本地模型确认模型是否真的支持 Embedding 接口。不是所有模型都能做 Embedding要使用专门的 Embedding 模型。6.2 检索结果不相关的根因分析检索结果不好和“LLM 能力差”没多大关系根子往往在索引质量上。重点检查三件事文本清洗Markdown 中的特殊符号、代码块、公式是否被过度切分切片粒度你的笔记段落是否太长或太碎Embedding 模型中文笔记配英文 Embedding 模型效果一定差。从实际经验看最值得优化的就是切片策略。按 Markdown 标题切分比按固定字符切分要自然得多每个切片控制在 500 到 800 字左右检索精度和上下文完整性都能兼顾。6.3 如何降低幻觉风险在研究中幻觉是最不能接受的问题。降低幻觉的实用手段按优先级排序强制溯源要求 LLM 回答时标注引用来源且禁止输出检索内容之外的信息。降低 temperature检索问答场景把 temperature 设到 0.10.3。提高检索质量检索不到内容就说“不知道”比强行回答好得多。人工复核关键事实涉及文献作者、年份、数据结果时必须回到原文核对。7. 最佳实践与工程建议7.1 知识组织规范研究知识库要长期积累组织规范决定了它能走多远。我的建议是按主题建目录而不是按时间。例如deep-learning/transformer.md、nlp/rag.md。每个文件有元信息头tags、source、date方便过滤和溯源。统一层级结构核心概念、关键公式、与经典方法对比、我的思考。这样切分后每个片段都有完整语义。记录未解问题把阅读中的疑问单独写在笔记末尾方便下次检索和回看。7.2 检索策略建议先做全库检索再做时间或标签过滤能显著提升检索质量。检索 Top-K 建议设置在 5 到 10 之间。太少容易漏太多会稀释上下文。对高频使用的笔记单独建立一个子集合避免和低频笔记互相干扰。7.3 安全与隐私边界研究资料中往往包含未发表的数据、内部技术方案甚至合作方的保密协议。使用 LLM 服务时务必注意不要把未公开的研究数据直接发送给第三方 API除非确认数据脱敏且许可合规。推荐优先使用本地模型如 Ollama、Llama.cpp处理敏感资料。如果必须使用云端 API至少做脱敏处理并检查服务条款中的数据使用约定。这一点在涉及企业项目或学术合作时尤其重要不要因为效率牺牲数据安全边界。7.4 可复现性与记录研究最重视可复现性。LLM 参与的研究过程天然带有随机性所以你需要额外做好记录记录每次问答使用的模型名称和版本。记录推理精度FP16/FP32/BF16。记录 temperature、top_p 等采样参数。如果是本地模型记录量化方式。建议在知识库中单独维护一个llm-experiments.md文件把每次重要的实验条件记录下来。这样即使几周后回头也能重建完全相同的提问环境。7.5 提示词模板管理不要让提示词散落在代码里。建议把所有固定提示词抽取到单独文件中# 文件路径prompts.py SYSTEM_PROMPT 你是一个严谨的科研助手回答要简洁、准确、有依据。 QA_PROMPT 请基于以下检索到的研究笔记内容回答问题。 如果笔记中没有相关内容请直接说“知识库中没有找到相关资料”不要编造。 回答时请标注引用来源。 检索到的内容 {context} 问题{query} SUMMARY_PROMPT 请对以下论文片段做结构化摘要包含 1. 研究问题 2. 方法核心 3. 实验结果 4. 局限性 论文片段 {content} 这样做的好处是改提示词不需要改代码逻辑也方便做 A/B 测试。7.6 成本控制研究项目的预算通常有限API 调用费用不可忽视。几个实用建议Embedding 模型便宜但高频调用也不少批量处理时合并请求。长文档问答时先用摘要模式压缩内容再进入 LLM显著降低 Token 消耗。本地模型在 GPU 不够时用 CPU 推理虽然慢但零成本适合低频处理。8. 总结与下一步学习路线这篇文章从研究者的实际需求出发梳理了 LLM 在研究场景中的四种使用层次信息检索、文献抽取、知识库构建、Agent 自动化流程。然后重点讲解了 LLM Wiki 范式、RAG 架构、向量检索、Agent 与 MCP 的核心概念并用完整代码实现了一个基于 Markdown 笔记的个人研究知识库。最后补充了模型精度选择、常见问题排查和工程化建议。如果你是从零开始我建议按下面的顺序逐步深入先把笔记格式规范起来统一 Markdown 结构。跑通本地向量化 检索问答的基础链路。加入更多 RAG 优化切片调整、检索过滤、引用标注。学习编排框架LangChain 或 LlamaIndex把手工代码封装成可复用服务。了解 Agent 和 MCP把重复性研究流程自动化。如果在搭建过程中遇到检索效果差、API 配置报错或模型精度选择等问题可以回来对照第 6 节的排查表逐项检查。核心思路是先保证链路跑通再逐步优化质量先解决“有没有”再追求“好不好”。如果你正在探索 LLM 辅助研究的方法希望这篇文章能给你一个清晰的起点。也欢迎在评论区分享你自己用 LLM 做研究的心得和踩坑经验。