大家好今天我们来聊一个很有意思、也很实际的问题。在技术社区里经常能看到这样一类提问Ask HN: How do you use LLMs for your research?翻译过来就是你在自己的研究流程里是怎么用大语言模型LLM的这个问题看起来简单但回答起来往往非常零散。有人用来读论文有人用来写代码有人用来整理笔记还有人直接搭了一套 Agent 工作流把每周的文献调研自动化了。作为一名经常要和论文、技术文档、源码打交道的开发者我对这个问题的体会很深。最近在整理个人知识库和文献调研流程时我也把 LLM、RAG、Agent 这些技术串了起来踩过不少坑也沉淀出一套能落地的方法。这篇文章就把这套方法完整拆开从最基础的概念讲到可运行的代码再讲到知识库搭建和工程化建议。本文适合下面这些读者刚开始接触 LLM想知道除了聊天还能拿它做什么做科研、做技术调研需要快速读文献、整理资料有编程基础想把 RAG、向量检索、Agent 落地到自己的知识库系统中已经在用 LLM 但效果不稳定想了解常见问题和排查思路。读完这篇文章你会掌握 LLM 在研究场景中的几种典型用法、一套最小可运行的 RAG 检索问答示例、一个基于本地 Markdown 笔记的个人知识库方案以及在不同精度、不同框架下做选择的思路。1. 背景与核心概念LLM 在研究场景中到底能干什么1.1 研究者为什么需要 LLM先看一个很常见的场景。你正在做一个跨领域的调研比如要研究“Spring AI 结合 MCP 协议实现 Agent 应用”。这个主题牵扯到 Spring 生态、AI 应用框架、RAG、Agent 编排、工具调用等多个方向。传统的做法可能是在搜索引擎里输入关键词逐个打开页面下载十几篇论文或技术文章边读边做笔记最后再汇总把重要结论整理成自己的知识体系。这个过程非常耗时而且很容易出现“读了很多资料但真正内化到知识库里的内容很少”的情况。问题不在于阅读速度而在于信息筛选和结构化的效率太低。LLM 正好能在这几个环节帮上忙信息压缩把几页论文摘要成几百字要点定向抽取按你定义的字段从多篇文档里提取结构化信息语义检索用自然语言去查资料而不是靠关键词精确匹配内容生成根据检索结果生成综述初稿、对比表格、技术方案代码辅助解释论文里的公式、把算法伪代码改写成 Python 实现。要注意LLM 不是学术搜索引擎。它不能保证引用的真实性也不能替代原文阅读。它的价值更像一个“助理”帮你把前期工作尽量压缩但最终的判断仍然要由你自己完成。1.2 从对话到研究工具几个容易混淆的概念在开始实操之前有几个概念需要区分清楚否则后面看代码会有点懵概念一句话解释在研究场景中的例子LLM大语言模型一个能理解和生成文本的模型ChatGPT、Claude、开源模型等RAG检索增强生成先检索资料再让模型回答从本地论文库中检索相关内容再生成回答Agent智能体能自己规划步骤并调用工具自动检索多篇论文并生成对比报告Embedding / 向量把文本变成一串数字用距离表示相似度把论文段落变成向量方便语义查找精度模型权重和运算时使用的数值类型fp16、fp32、bf16影响显存和速度这些概念在研究工作流里通常是配合使用的。比如最基础的“LLM 问答”只是把问题发给模型模型直接回答。这种方式适合常识性问题但不适合回答“你本地那 200 篇论文里有什么结论”因为模型没有见过这些资料。于是就有了 RAG。RAG 把“检索”和“生成”结合在一起先从你的资料库中检索出相关的段落再把这些段落作为上下文交给 LLM 生成回答。这样回答就有据可查。再进一步如果把这个流程拆成多个步骤让 LLM 决定“先查什么、再查什么、用什么工具去查”那就是 Agent。Agent 适合更复杂的任务比如综合多个数据源做调研报告。2. 常见应用模式研究流程中的 LLM 使用方式从我和身边开发者的实践来看LLM 在研究中的应用基本可以分成四个层次。你可以根据自己的需求选择从哪一档切入。2.1 一次性问答与快速摘要这是最简单的一种模式适合处理“一两篇文章”级别的输入。比如你拿到一篇 PDF 论文直接拖动到支持长上下文的对话工具中然后问这篇论文要解决什么问题核心方法是什么实验结论怎么样有哪些局限性这种方式成本低、上手快不需要写代码。缺点是无法积累成知识库每次都要重复操作而且当资料变多、上下文超过限制时模型会遗忘前文。2.2 结构化信息抽取比问答更进阶一点的是结构化抽取。你可以让 LLM 按固定格式输出论文信息比如标题作者发表年份解决的问题使用的方法实验数据集主要结论局限性把多篇论文交给模型让模型批量生成这样的卡片再统一归档。这种方式非常适合写文献综述的前期准备。结构化抽取的关键是给出明确的输出模板。模板越具体输出越稳定。你可以用 JSON 格式来定义模板方便后续程序处理。2.3 基于 RAG 的知识库问答当资料量从几篇增长到几十、几百篇时一次性把全文塞给模型就不太现实了。一方面受到上下文窗口限制另一方面成本也会增加。RAG 是这一阶段最常用的方案。它的基本思路是把所有文档切分成小块将每一块转换成向量Embedding把向量存储到向量数据库中用户提问时把问题也转换成向量从向量库中召回最相关的若干块将这些块作为上下文连同用户问题一起交给 LLM 生成回答。RAG 最大的优点是可扩展、可追溯。资料更新时只需要增量更新向量库回答时可以引用具体段落来源。2.4 基于 Agent 的多步骤工作流如果任务不是“回答一个问题”而是“完成一项调研”那 Agent 就更有优势。例如帮我调研一下最近三个月关于“检索增强生成RAG在金融领域的应用”的论文输出一份综述。Agent 可以自己拆解步骤查找关键词搜索论文数据库对结果去重和过滤逐个摘要综合成报告。这个过程中可能涉及搜索引擎调用、数据库查询、代码执行等多种工具。Agent 的核心价值在于编排而不是“更聪明的回答”。下表可以帮你快速定位自己需要哪个层次使用模式资料量级是否需要代码典型工具快速问答1-2 篇不需要各类对话产品结构化抽取几篇到十几篇可选Prompt 表格RAG 知识库几十到几百篇需要向量数据库 框架Agent 工作流持续增长需要编排框架 工具调用3. 环境准备与精度问题本地跑 LLM 必须知道的事如果你只想用现成的在线服务环境准备很简单。但如果你想在自己机器上跑模型、搭知识库那么环境、精度、显存这几个问题绕不开。尤其是“精度”这个问题很多初学者在这里栽跟头。3.1 三条技术路线怎么选按照项目阶段和使用场景我一般把环境准备分成三条路线路线一纯在线服务适合刚开始学习、对数据隐私没有特别要求的情况。只需要注册 API Key通过 HTTP 接口调用模型。优势是省事劣势是敏感数据不能进。路线二本地推理引擎适合离线环境、数据敏感、或者想深入理解模型运行的场景。需要准备 GPU 或性能较好的 CPU安装推理引擎下载模型文件。这里会接触到精度和量化问题。路线三在线 API 本地框架结合这是目前我比较推荐的项目落地方式。在线 API 负责大模型推理本地框架负责资料管理、检索、编排。这样既能用到较强的基础模型又能控制敏感数据的流向同时代码逻辑完全掌握在自己手里。版本说明由于 LLM 生态迭代非常快不同的框架、工具、模型版本之间可能存在兼容性问题。本文示例以常见环境为例重点演示配置思路。你实际使用时应根据项目版本调整依赖不要盲目复制版本号。3.2 fp16、fp32、bf16LLM 精度问题详解这是一个很容易被忽略但实际开发中影响很大的知识点。LLM 的权重和中间计算都需要用浮点数表示。浮点数的“精度”直接决定了模型能否稳定推断也决定了显存占用和计算速度。常见的有三种格式精度类型位宽表示范围特点fp3232 位大精度高显存占用大速度相对慢fp1616 位中等精度适中显存减半但存在数值溢出风险bf1616 位与 fp32 类似的范围牺牲尾数精度保留大范围适合训练和稳定推理在 GPU 上fp32 每个数占 4 字节fp16 和 bf16 每个数占 2 字节。也就是说同样大小的模型用 fp16 加载只需要 fp32 一半的显存。fp16 的问题在于“范围不够大”。如果数值很小或很大fp16 容易溢出导致训练不稳定。bf16 专门解决了这个问题它用更多的位来保存指数因此表示的数值范围和 fp32 几乎一样虽然尾数精度更低但在深度学习中常常够用。所以你会看到这样的实践训练阶段常见用 bf16 混合精度既能降低显存又能保持较稳定的训练推理阶段常见用 fp16 或 INT8 量化目的是提高速度、降低资源消耗结果敏感的场景如果对精度有怀疑可以切回 fp32 做一次对比验证。实战中的建议是优先尝试 fp16 或 bf16如果出现输出质量明显下降、数值异常、训练发散等情况再检查是否与精度有关。不要一上来就追求 fp32因为显存成本和速度成本都很高。3.3 最小环境清单这里给一个最小的环境清单适合本地做 RAG 实验。不写死具体版本因为不同时期推荐版本会变化但环境类型是固定的操作系统Windows / Linux / macOS 均可Python3.9 或以上包管理工具pip 或 conda运行时在线 API 需要一个可用的 API Key本地推理需要安装推理引擎、下载模型文件向量存储可以使用开源向量库或者直接用内存中的向量索引做小规模实验界面工具如果只写脚本终端就够用如果要做成工具可以用 gradio 或 streamlit。下面是一个 requirements.txt 的示例。它只是一个参考结构具体版本请按你的实际环境调整。# 文件路径requirements.txt # 注意版本号仅作示意请根据实际环境安装 openai1.0.0 langchain0.1.0 chromadb0.4.0 pypdf3.17.0 python-dotenv1.0.0如果你的项目涉及 Java 生态也可以考虑 Spring AI 这类框架它能把 LLM、向量库、工具调用整合到 Spring 体系中适合已有 Java 后端团队平滑接入。4. 实战案例一个最小可运行的 RAG 检索问答系统接下来进入核心部分。我们来实现一个最小可运行的检索问答系统目的是让你理解 RAG 的完整流程。示例使用 Python采用模块化写法。每个模块说明清楚之后你可以根据自己的资料类型和业务场景替换。4.1 创建项目结构我们先创建一个项目目录mkdir llm-research-rag cd llm-research-rag项目结构如下llm-research-rag/ ├── data/ │ └── sample_paper.txt ├── src/ │ ├── __init__.py │ ├── loader.py │ ├── splitter.py │ ├── retriever.py │ └── generator.py ├── config.py ├── requirements.txt └── run.pydata目录放原始资料src目录放核心代码config.py放配置run.py是主入口。4.2 定义配置文件先写config.py。这里统一管理 API Key、模型名、向量模型名、文件路径等配置。这样后续维护起来方便。# 文件路径config.py import os # 从环境变量读取 API Key避免写死在代码里 API_KEY os.getenv(LLM_API_KEY, ) BASE_URL os.getenv(LLM_BASE_URL, https://api.openai.com/v1) API_MODEL gpt-4o-mini EMBEDDING_MODEL text-embedding-3-small # 本地向量索引保存路径 VECTOR_STORE_DIR ./vector_store # 原始资料目录 DATA_DIR ./data # 文档切分参数 CHUNK_SIZE 500 CHUNK_OVERLAP 50 # 检索返回的文档块数量 TOP_K 3这里特别强调一下 API Key 的管理。不要直接把真实 Key 写进代码或提交到 Git 仓库。推荐的做法是设置环境变量或者使用.env文件并且把.env加入.gitignore。4.3 编写文档加载与切分模块加载模块负责读取原始文件。为了简单这里先以纯文本文件为例。实际项目中你可能需要支持 PDF、Word、Markdown 等格式。加载 PDF 时可以使用pypdf或pymupdf加载 Word 时可以使用python-docx。# 文件路径src/loader.py def load_document(file_path: str) - str: 加载文本文件内容。 实际项目中可以根据扩展名选择不同的解析器。 with open(file_path, r, encodingutf-8) as f: return f.read()切分模块是整个流程里容易被忽略但非常重要的环节。切分太大检索时噪声多切分太小段落语义不完整。这里提供一个按字符数切分并带重叠区域的实现。# 文件路径src/splitter.py def split_text(text: str, chunk_size: int 500, overlap: int 50) - list[str]: 将长文本切分成多个块块之间保留 overlap 个字符的重叠。 重叠区域可以避免语义在切分边界被截断。 chunks [] start 0 while start len(text): end start chunk_size chunk text[start:end] if chunk: chunks.append(chunk) if end len(text): break start end - overlap return chunks这种简单的切分方式适合演示。工程化时你可以考虑按标题、段落、句子结构来做智能切分尤其是 Markdown 和论文这类结构化文档。4.4 编写向量化与检索模块检索模块要做两件事把文档块转成向量根据用户问题召回最相关的块。大部分向量数据库提供了相似的 API插入、查询、持久化。这里我用一个抽象版本展示思路。你可以把它替换成 Chroma、FAISS、Milvus、Qdrant 等具体实现。# 文件路径src/retriever.py from config import EMBEDDING_MODEL, TOP_K class VectorStore: def __init__(self, api_key: str): # 实际项目中这里会连接向量数据库 # 示例中我们用一个列表模拟 self.vectors [] self.texts [] self.api_key api_key def add_documents(self, docs: list[str]): 将文档转成向量并存储。 这里的关键是调用 Embedding API。 for doc in docs: vector self._get_embedding(doc) self.vectors.append(vector) self.texts.append(doc) def query(self, question: str, top_k: int TOP_K) - list[str]: 将问题转成向量然后召回最相似的文档块。 question_vector self._get_embedding(question) scored [] for i, vector in enumerate(self.vectors): score self._cosine_similarity(vector, question_vector) scored.append((score, i)) scored.sort(keylambda x: x[0], reverseTrue) return [self.texts[i] for _, i in scored[:top_k]] def _get_embedding(self, text: str): # 该函数应调用 Embedding API 或本地 embedding 模型 # 返回一个向量例如 list[float] raise NotImplementedError(请根据你的 Embedding 服务实现) def _cosine_similarity(self, vec1, vec2): raise NotImplementedError(请根据向量表示实现余弦相似度计算)请注意上面代码里的两个raise NotImplementedError是需要你根据自己的 Embedding 服务补全的。如果你使用在线 Embedding API一般是这样def _get_embedding(self, text: str): import requests response requests.post( f{BASE_URL}/embeddings, headers{Authorization: fBearer {self.api_key}}, json{model: EMBEDDING_MODEL, input: text} ) response.raise_for_status() return response.json()[data][0][embedding]如果你使用本地模型比如sentence-transformers则会是另一种写法。余弦相似度计算也比较标准import math def _cosine_similarity(self, vec1, vec2): dot sum(a * b for a, b in zip(vec1, vec2)) norm1 math.sqrt(sum(a * a for a in vec1)) norm2 math.sqrt(sum(b * b for b in vec2)) if norm1 0 or norm2 0: return 0.0 return dot / (norm1 * norm2)这样你就有了一个最核心的检索模块。真正工程化时我会建议直接用成熟的向量数据库而不是自己维护列表。但对于理解原理这个版本足够清晰。4.5 编写生成模块生成模块负责把检索到的上下文拼装成提示词然后调用大模型生成回答。提示词的质量决定了回答的质量。# 文件路径src/generator.py from config import API_MODEL, BASE_URL class LLMGenerator: def __init__(self, api_key: str): self.api_key api_key self.base_url BASE_URL self.model API_MODEL def generate(self, question: str, contexts: list[str]) - str: prompt self._build_prompt(question, contexts) # 这里调用对话补全接口 # 为了演示用 requests 实现一个简化版本 import requests response requests.post( f{self.base_url}/chat/completions, headers{Authorization: fBearer {self.api_key}}, json{ model: self.model, messages: [ {role: system, content: 你是一个研究助手请根据给定的参考资料回答问题。回答要简洁、准确并注明信息来源。}, {role: user, content: prompt} ] } ) response.raise_for_status() return response.json()[choices][0][message][content] def _build_prompt(self, question: str, contexts: list[str]) - str: context_text \n\n---\n\n.join(contexts) return f请根据下面的参考资料回答用户问题。 参考资料 {context_text} 用户问题 {question} 回答要求 1. 如果参考资料无法回答问题请直接说明“根据现有资料无法回答”。 2. 回答中请标注关键信息来自哪个参考资料。 3. 不要编造参考资料中不存在的信息。这里的关键点有两个。第一提示词里给模型划定了回答边界要求它不能凭空回答。这能大幅降低“幻觉”问题。第二把多个上下文块拼在一起时要有清晰的分隔标识方便模型区分不同来源。4.6 主流程串联最后用run.py把这个流程串起来。# 文件路径run.py import os from config import API_KEY, DATA_DIR, CHUNK_SIZE, CHUNK_OVERLAP from src.loader import load_document from src.splitter import split_text from src.retriever import VectorStore from src.generator import LLMGenerator def main(): if not API_KEY: print(请先设置 LLM_API_KEY 环境变量) return # 1. 加载并切分文档 paper_path os.path.join(DATA_DIR, sample_paper.txt) raw_text load_document(paper_path) chunks split_text(raw_text, CHUNK_SIZE, CHUNK_OVERLAP) print(f切分完成共 {len(chunks)} 个文本块) # 2. 建立向量索引 store VectorStore(api_keyAPI_KEY) store.add_documents(chunks) print(向量索引建立完成) # 3. 检索并生成 question 这篇论文提出的方法是什么 contexts store.query(question) generator LLMGenerator(api_keyAPI_KEY) answer generator.generate(question, contexts) print(回答) print(answer) if __name__ __main__: main()4.7 运行与验证准备一份测试文本data/sample_paper.txt内容可以是任意一段技术描述。然后运行export LLM_API_KEY你的APIKey python run.py预期输出分几步切分完成共 12 个文本块 向量索引建立完成 回答 该论文提出的核心方法主要是……如果检索结果不太相关建议先检查CHUNK_SIZE和TOP_K这两个参数。检索不精准时可以调大TOP_K上下文太长时可以调小CHUNK_SIZE。4.8 结果说明从这个小示例中你可以清楚地看到 RAG 的完整链路文档加载负责读取资料文档切分决定检索的基本单元向量化把文本变为可计算的向量检索找出最相关的文本块生成把相关文本块交给 LLM产出有依据的回答。这个链路就是各种“知识库问答”“文档助手”的核心骨架。后面不管换什么框架、什么向量数据库本质逻辑都是这样的。5. 个人知识库实战Obsidian LLM Wiki 工作流热词里经常能看到“Obsidian LLM Wiki 搭建个人知识库”。顺着上面的 RAG 思路我们完全可以自己搭建一个轻量级的个人知识库系统。5.1 什么是 LLM Wiki 范式“LLM Wiki”这个概念核心思想是把个人笔记库当作一个可以“对话”的 Wiki。传统的 Wiki 靠人工整理目录和链接而 LLM Wiki 则让你直接用自然语言提问系统自动从笔记中检索相关内容并给出回答。这个范式很适合作研究笔记因为它解决了两个痛点笔记写完之后很难被再次找到笔记之间缺少语义关联关键词搜索覆盖不全。配合 Obsidian 这类本地 Markdown 笔记工具你的每篇笔记本身就是一个信息单元。我们可以用一个 Python 脚本把这些 Markdown 文件全部扫描、切分、向量化然后提供问答接口。5.2 扫描本地 Markdown 笔记并生成向量索引下面给出一个简化版的脚本思路。它做三件事扫描目录下的.md文件切分内容生成向量索引并保存。# 文件路径build_index.py import os import glob from config import DATA_DIR, EMBEDDING_MODEL def scan_markdown_files(root_dir: str) - list[tuple[str, str]]: 返回 [(文件相对路径, 文件内容), ...] results [] for file_path in glob.glob(os.path.join(root_dir, **, *.md), recursiveTrue): with open(file_path, r, encodingutf-8) as f: content f.read() rel_path os.path.relpath(file_path, root_dir) results.append((rel_path, content)) return results def build_index(): notes scan_markdown_files(./notes) all_chunks [] metadatas [] for rel_path, content in notes: # 这里可以复用之前写好的 split_text chunks split_text(content, 300, 30) for chunk in chunks: all_chunks.append(chunk) metadatas.append({source: rel_path}) print(f扫描到 {len(notes)} 个笔记文件切分成 {len(all_chunks)} 个文本块) # 将 all_chunks 向量化并保存到本地向量库 # 工程化时建议使用 Chroma / FAISS / LanceDB 等 # 这里先打印出前几个块方便你确认效果 for i, chunk in enumerate(all_chunks[:3]): print(f--- chunk {i} ---) print(chunk[:100]) if __name__ __main__: build_index()实际工程化时你可以把all_chunks和metadatas一起写入向量数据库。每个文本块都要记录它来自哪个文件这样回答时可以带上来源路径。5.3 增加“引用来源”的回答格式在研究场景中引用来源非常重要。无论你是基于 RAG 做问答还是基于 Agent 做报告都应该让回答附带来源。实践中我习惯在提示词里明确要求模型引用编号然后在后端把编号映射成文件路径。def format_citations(contexts: list[str], metadatas: list[str]) - str: 为每个上下文块编号并标注来源。 blocks [] for idx, (text, source) in enumerate(zip(contexts, metadatas)): blocks.append(f[{idx 1}] 来源: {source}\n{text}) return \n\n.join(blocks)这样的回答格式在阅读时能快速回溯原文非常实用。6. 从 RAG 到 Agent为什么需要编排框架当你把 RAG、工具调用、多轮记忆、任务规划组合到一起时代码会越来越复杂。这时候就轮到“编排框架”登场。热词里有“llm 应用为什么需要编排框架”这确实是一个值得思考的问题。让我用一个例子来解释。假设你要实现一个文献调研助手它需要根据研究主题生成检索关键词调用学术搜索 API 搜索论文下载和解析 PDF把论文内容写入向量库最后生成综述报告。如果不用编排框架你需要自己管理每一步的状态、错误处理、重试、上下文的拼接。代码会变成一串长长的函数调用链。而编排框架的价值就是把这套流程抽象成可配置、可维护的模块。6.1 Python 生态与 Java 生态的典型选择在 Python 生态中LangChain 和 LlamaIndex 是比较常见的框架。它们提供了文档加载器、文本切分器、向量库封装、Agent 工具调用等模块能显著降低开发成本。在 Java 生态中Spring AI 是一个值得关注的选择。它借鉴了 Spring 的模块化思想把模型接入、向量存储、工具调用都做成了可配置组件适合已经有 Spring Boot 后端的团队。MCP 也值得了解。它是一个模型上下文协议用于让模型之间、模型与工具之间、应用之间以标准化方式交换上下文。当你需要把多个能力组合成复杂应用时类似 MCP 这样的标准化协议可以减少“胶水代码”。6.2 一个配置化工作流的简化示例下面是一个 YAML 风格的配置片段用来表示一个简单的调研工作流定义。它之所以用 YAML 而不是代码是因为工程上我们希望把流程定义和业务逻辑分离。# 文件路径research_workflow.yaml workflow: name: literature_review steps: - name: generate_query type: llm prompt: 根据用户研究主题生成3个搜索关键词 - name: search_papers type: tool tool: academic_search_api params: query: {{steps.generate_query.output}} - name: download_and_parse type: tool tool: pdf_parser params: urls: {{steps.search_papers.output}} - name: summarize type: llm prompt: 对每篇论文生成结构化摘要 - name: write_review type: llm prompt: 根据所有摘要生成综述报告这个配置展示了编排框架的一个核心思想让流程步骤成为可配置的数据让每一步的输出成为下一步的输入。这样你可以快速调整流程而不用改大量业务代码。在实际项目中我建议先把一个最简流程跑通再逐步添加工具和分支逻辑。一开始就设计复杂的 Agent 图很容易让项目失控。7. 常见问题与排查思路在搭建 LLM 研究工具的过程中很多问题都是有规律可循的。这里整理一份高频问题排查表。问题现象常见原因解决思路调用向量 API 时提示“文本向量 API 未配置”没有设置 API Key 或配置的模型名错误检查环境变量、配置文件确认向量模型名是否可用本地跑模型显存溢出加载精度过高比如直接用 fp32改用 fp16 或 bf16必要时使用量化版本检索结果完全不相关切分太大导致语义混杂或向量模型不匹配调小 chunk size增加 overlap检查 embedding 模型是否与查询语言一致回答出现编造内容上下文中缺少足够信息模型只能“猜”在 Prompt 中明确要求“无依据时拒绝回答”并增加检索召回数量上下文太长超出模型限制召回的文本块过多或单块太长减少 TOP_K调小 chunk size优先使用摘要作为上下文响应速度很慢模型参数大、GPU 性能不足或网络延迟尝试小模型、降低精度、对运行环境做性能测试Agent 工作流卡在某个工具调用上工具入参不符合 API 要求检查工具定义、参数映射与日志同一套代码在不同机器效果不一致依赖版本、模型版本或精度配置不同锁定版本记录环境差异使用配置文件统一参数另一个在我实际开发中经常出现的问题是把本地文件全部加载后直接让模型读。这种做法在小项目里可行但一旦文件增多不仅上下文占用大回答质量也会下降。RAG 就是用来解决这个问题的但很多人第一次使用 RAG 时忽略了“切分质量”。切分质量直接影响检索效果。切分过细一个完整方法描述可能被拆成两半切分过粗每个块里包含太多无关信息检索的精确度下降。我的经验是先观察 2-3 个典型查询的召回结果再针对性调整切分参数而不是一上来就追求复杂的切分算法。8. 最佳实践与工程建议最后这部分我想结合研究场景给出一套比较务实的工程建议。这些建议不针对某一个具体框架而是适用于大部分 LLM 应用项目。8.1 简单优先先用最小的方案跑通很多人在初期容易陷入“框架焦虑”还没跑通最简问答就在纠结要不要上 Agent、要不要上编排框架。我的建议是分阶段推进先用在线对话工具验证 Prompt 思路然后写一个最小脚本实现 RAG 链路再考虑引入框架和向量数据库最后才根据需求加上 Agent 编排。每一步都建立在前一步的可运行成果之上。这样出现问题容易定位开发体验也好很多。8.2 做好提示词版本管理研究场景中的 Prompt 往往需要频繁调试。Prompt 也是代码应该纳入项目管理。建议在项目里单独建一个prompts/目录每个模板一个文件并在文件头部写明用途、输入输出格式、修改日期。prompts/ ├── summary.md ├── literature_review.md ├── code_explainer.md └── qa_with_context.md这样可以避免“改着改着忘了之前版本的效果”这种尴尬情况。8.3 重视数据隐私与合规边界在研究工作中有些资料可能是未公开的论文、项目计划书、内部文档。使用在线 LLM API 时这些数据会发送给服务商。建议做如下分级公开资料可以使用在线 API内部数据使用本地模型或在合规的私有化环境中调用敏感数据强烈建议在本地推理引擎中运行并严格限制访问权限。不要因为贪图方便把敏感数据直接送入在线服务。这不仅是合规问题更是对自己研究负责的基本要求。8.4 关注可观测性与日志LLM 应用有一个特点同样的输入输出可能每次都不一样。因此可观测性非常重要。建议至少记录以下信息用户问题最终使用的 Prompt检索到的上下文块及各自来源模型返回内容耗时与 token 消耗调用的模型版本与参数。有了这些日志你才能在问题出现时复现和定位。否则一句“我昨天还能用今天就不行了”会把你带入漫长的猜测中。8.5 安全边界与最小权限如果你在项目中集成了数据库查询、代码执行等工具一定要遵循最小权限原则。当 Agent 可以调用工具时它不应该拥有比你更高的权限。具体来说数据库账号只授予必要的 SELECT 权限代码执行工具运行在沙箱中删除、更新等危险操作需要人工二次确认对外发布的接口要做访问认证和限流。这些原则听起来是后端常识但在 LLM Agent 场景中往往容易被忽略。一个自主规划并调用工具的 Agent如果没有权限边界风险会被明显放大。8.6 预留人工审核环节研究场景里LLM 的输出不能直接当作最终结论。不管是用 RAG 做文献综述还是用 Agent 做数据调研都要有人工审核环节。这也是我认为在研究场景中使用 LLM 最重要的一条建议。你可以让 LLM 生成初稿但要在流程上设计“人工确认”节点。比如输出报告前必须由研究者检查引用来源删除有疑虑的段落修正不准确的信息。真正的效率提升来自“人机协作”而不是把判断权完全交给模型。9. 总结与后续学习方向从一个社区提问开始我们从概念到代码把 LLM 在研究场景中的应用方式梳理了一遍。这篇文章里你应该已经掌握了几个关键内容LLM 在研究场景中的四个应用层次问答摘要、结构化抽取、RAG 知识库、Agent 工作流本地推理中 fp16、fp32、bf16 精度问题的基本概念和选择思路一个最小可运行的 RAG 检索问答系统的完整代码和运行流程基于 Obsidian LLM Wiki 思路的个人知识库搭建方法编排框架的价值以及常见问题排查和工程化建议。下一步如果你想继续深入可以根据自己的兴趣选择一个方向如果你想强化工程能力可以深入研究 LangChain、LlamaIndex 或 Spring AI 的源码如果你想优化检索质量可以学习向量数据库的原理以及分块策略的进阶方法如果你想做 Agent 应用可以从一个简单的工具调用开始逐步增加任务规划如果你关心模型运行效率可以继续学习量化、推理引擎、混合精度训练等底层知识。在实际项目中我建议你先从一个不超过 50 篇文档的小型知识库开始。把数据准备好跑通 RAG 链路然后观察真实查询的效果再逐渐扩大规模。LLM 生态发展很快但只要把基础概念和工程习惯打牢无论工具怎么变你都能快速迁移。如果这篇文章对你有帮助建议收藏备用。你也可以顺着其中的某一节亲手跑一个最小示例那会比只看文章收获大得多。 从RAG到Agent：用LLM搭建个人科研知识库的完整实践指南
大家好今天我们来聊一个很有意思、也很实际的问题。在技术社区里经常能看到这样一类提问Ask HN: How do you use LLMs for your research?翻译过来就是你在自己的研究流程里是怎么用大语言模型LLM的这个问题看起来简单但回答起来往往非常零散。有人用来读论文有人用来写代码有人用来整理笔记还有人直接搭了一套 Agent 工作流把每周的文献调研自动化了。作为一名经常要和论文、技术文档、源码打交道的开发者我对这个问题的体会很深。最近在整理个人知识库和文献调研流程时我也把 LLM、RAG、Agent 这些技术串了起来踩过不少坑也沉淀出一套能落地的方法。这篇文章就把这套方法完整拆开从最基础的概念讲到可运行的代码再讲到知识库搭建和工程化建议。本文适合下面这些读者刚开始接触 LLM想知道除了聊天还能拿它做什么做科研、做技术调研需要快速读文献、整理资料有编程基础想把 RAG、向量检索、Agent 落地到自己的知识库系统中已经在用 LLM 但效果不稳定想了解常见问题和排查思路。读完这篇文章你会掌握 LLM 在研究场景中的几种典型用法、一套最小可运行的 RAG 检索问答示例、一个基于本地 Markdown 笔记的个人知识库方案以及在不同精度、不同框架下做选择的思路。1. 背景与核心概念LLM 在研究场景中到底能干什么1.1 研究者为什么需要 LLM先看一个很常见的场景。你正在做一个跨领域的调研比如要研究“Spring AI 结合 MCP 协议实现 Agent 应用”。这个主题牵扯到 Spring 生态、AI 应用框架、RAG、Agent 编排、工具调用等多个方向。传统的做法可能是在搜索引擎里输入关键词逐个打开页面下载十几篇论文或技术文章边读边做笔记最后再汇总把重要结论整理成自己的知识体系。这个过程非常耗时而且很容易出现“读了很多资料但真正内化到知识库里的内容很少”的情况。问题不在于阅读速度而在于信息筛选和结构化的效率太低。LLM 正好能在这几个环节帮上忙信息压缩把几页论文摘要成几百字要点定向抽取按你定义的字段从多篇文档里提取结构化信息语义检索用自然语言去查资料而不是靠关键词精确匹配内容生成根据检索结果生成综述初稿、对比表格、技术方案代码辅助解释论文里的公式、把算法伪代码改写成 Python 实现。要注意LLM 不是学术搜索引擎。它不能保证引用的真实性也不能替代原文阅读。它的价值更像一个“助理”帮你把前期工作尽量压缩但最终的判断仍然要由你自己完成。1.2 从对话到研究工具几个容易混淆的概念在开始实操之前有几个概念需要区分清楚否则后面看代码会有点懵概念一句话解释在研究场景中的例子LLM大语言模型一个能理解和生成文本的模型ChatGPT、Claude、开源模型等RAG检索增强生成先检索资料再让模型回答从本地论文库中检索相关内容再生成回答Agent智能体能自己规划步骤并调用工具自动检索多篇论文并生成对比报告Embedding / 向量把文本变成一串数字用距离表示相似度把论文段落变成向量方便语义查找精度模型权重和运算时使用的数值类型fp16、fp32、bf16影响显存和速度这些概念在研究工作流里通常是配合使用的。比如最基础的“LLM 问答”只是把问题发给模型模型直接回答。这种方式适合常识性问题但不适合回答“你本地那 200 篇论文里有什么结论”因为模型没有见过这些资料。于是就有了 RAG。RAG 把“检索”和“生成”结合在一起先从你的资料库中检索出相关的段落再把这些段落作为上下文交给 LLM 生成回答。这样回答就有据可查。再进一步如果把这个流程拆成多个步骤让 LLM 决定“先查什么、再查什么、用什么工具去查”那就是 Agent。Agent 适合更复杂的任务比如综合多个数据源做调研报告。2. 常见应用模式研究流程中的 LLM 使用方式从我和身边开发者的实践来看LLM 在研究中的应用基本可以分成四个层次。你可以根据自己的需求选择从哪一档切入。2.1 一次性问答与快速摘要这是最简单的一种模式适合处理“一两篇文章”级别的输入。比如你拿到一篇 PDF 论文直接拖动到支持长上下文的对话工具中然后问这篇论文要解决什么问题核心方法是什么实验结论怎么样有哪些局限性这种方式成本低、上手快不需要写代码。缺点是无法积累成知识库每次都要重复操作而且当资料变多、上下文超过限制时模型会遗忘前文。2.2 结构化信息抽取比问答更进阶一点的是结构化抽取。你可以让 LLM 按固定格式输出论文信息比如标题作者发表年份解决的问题使用的方法实验数据集主要结论局限性把多篇论文交给模型让模型批量生成这样的卡片再统一归档。这种方式非常适合写文献综述的前期准备。结构化抽取的关键是给出明确的输出模板。模板越具体输出越稳定。你可以用 JSON 格式来定义模板方便后续程序处理。2.3 基于 RAG 的知识库问答当资料量从几篇增长到几十、几百篇时一次性把全文塞给模型就不太现实了。一方面受到上下文窗口限制另一方面成本也会增加。RAG 是这一阶段最常用的方案。它的基本思路是把所有文档切分成小块将每一块转换成向量Embedding把向量存储到向量数据库中用户提问时把问题也转换成向量从向量库中召回最相关的若干块将这些块作为上下文连同用户问题一起交给 LLM 生成回答。RAG 最大的优点是可扩展、可追溯。资料更新时只需要增量更新向量库回答时可以引用具体段落来源。2.4 基于 Agent 的多步骤工作流如果任务不是“回答一个问题”而是“完成一项调研”那 Agent 就更有优势。例如帮我调研一下最近三个月关于“检索增强生成RAG在金融领域的应用”的论文输出一份综述。Agent 可以自己拆解步骤查找关键词搜索论文数据库对结果去重和过滤逐个摘要综合成报告。这个过程中可能涉及搜索引擎调用、数据库查询、代码执行等多种工具。Agent 的核心价值在于编排而不是“更聪明的回答”。下表可以帮你快速定位自己需要哪个层次使用模式资料量级是否需要代码典型工具快速问答1-2 篇不需要各类对话产品结构化抽取几篇到十几篇可选Prompt 表格RAG 知识库几十到几百篇需要向量数据库 框架Agent 工作流持续增长需要编排框架 工具调用3. 环境准备与精度问题本地跑 LLM 必须知道的事如果你只想用现成的在线服务环境准备很简单。但如果你想在自己机器上跑模型、搭知识库那么环境、精度、显存这几个问题绕不开。尤其是“精度”这个问题很多初学者在这里栽跟头。3.1 三条技术路线怎么选按照项目阶段和使用场景我一般把环境准备分成三条路线路线一纯在线服务适合刚开始学习、对数据隐私没有特别要求的情况。只需要注册 API Key通过 HTTP 接口调用模型。优势是省事劣势是敏感数据不能进。路线二本地推理引擎适合离线环境、数据敏感、或者想深入理解模型运行的场景。需要准备 GPU 或性能较好的 CPU安装推理引擎下载模型文件。这里会接触到精度和量化问题。路线三在线 API 本地框架结合这是目前我比较推荐的项目落地方式。在线 API 负责大模型推理本地框架负责资料管理、检索、编排。这样既能用到较强的基础模型又能控制敏感数据的流向同时代码逻辑完全掌握在自己手里。版本说明由于 LLM 生态迭代非常快不同的框架、工具、模型版本之间可能存在兼容性问题。本文示例以常见环境为例重点演示配置思路。你实际使用时应根据项目版本调整依赖不要盲目复制版本号。3.2 fp16、fp32、bf16LLM 精度问题详解这是一个很容易被忽略但实际开发中影响很大的知识点。LLM 的权重和中间计算都需要用浮点数表示。浮点数的“精度”直接决定了模型能否稳定推断也决定了显存占用和计算速度。常见的有三种格式精度类型位宽表示范围特点fp3232 位大精度高显存占用大速度相对慢fp1616 位中等精度适中显存减半但存在数值溢出风险bf1616 位与 fp32 类似的范围牺牲尾数精度保留大范围适合训练和稳定推理在 GPU 上fp32 每个数占 4 字节fp16 和 bf16 每个数占 2 字节。也就是说同样大小的模型用 fp16 加载只需要 fp32 一半的显存。fp16 的问题在于“范围不够大”。如果数值很小或很大fp16 容易溢出导致训练不稳定。bf16 专门解决了这个问题它用更多的位来保存指数因此表示的数值范围和 fp32 几乎一样虽然尾数精度更低但在深度学习中常常够用。所以你会看到这样的实践训练阶段常见用 bf16 混合精度既能降低显存又能保持较稳定的训练推理阶段常见用 fp16 或 INT8 量化目的是提高速度、降低资源消耗结果敏感的场景如果对精度有怀疑可以切回 fp32 做一次对比验证。实战中的建议是优先尝试 fp16 或 bf16如果出现输出质量明显下降、数值异常、训练发散等情况再检查是否与精度有关。不要一上来就追求 fp32因为显存成本和速度成本都很高。3.3 最小环境清单这里给一个最小的环境清单适合本地做 RAG 实验。不写死具体版本因为不同时期推荐版本会变化但环境类型是固定的操作系统Windows / Linux / macOS 均可Python3.9 或以上包管理工具pip 或 conda运行时在线 API 需要一个可用的 API Key本地推理需要安装推理引擎、下载模型文件向量存储可以使用开源向量库或者直接用内存中的向量索引做小规模实验界面工具如果只写脚本终端就够用如果要做成工具可以用 gradio 或 streamlit。下面是一个 requirements.txt 的示例。它只是一个参考结构具体版本请按你的实际环境调整。# 文件路径requirements.txt # 注意版本号仅作示意请根据实际环境安装 openai1.0.0 langchain0.1.0 chromadb0.4.0 pypdf3.17.0 python-dotenv1.0.0如果你的项目涉及 Java 生态也可以考虑 Spring AI 这类框架它能把 LLM、向量库、工具调用整合到 Spring 体系中适合已有 Java 后端团队平滑接入。4. 实战案例一个最小可运行的 RAG 检索问答系统接下来进入核心部分。我们来实现一个最小可运行的检索问答系统目的是让你理解 RAG 的完整流程。示例使用 Python采用模块化写法。每个模块说明清楚之后你可以根据自己的资料类型和业务场景替换。4.1 创建项目结构我们先创建一个项目目录mkdir llm-research-rag cd llm-research-rag项目结构如下llm-research-rag/ ├── data/ │ └── sample_paper.txt ├── src/ │ ├── __init__.py │ ├── loader.py │ ├── splitter.py │ ├── retriever.py │ └── generator.py ├── config.py ├── requirements.txt └── run.pydata目录放原始资料src目录放核心代码config.py放配置run.py是主入口。4.2 定义配置文件先写config.py。这里统一管理 API Key、模型名、向量模型名、文件路径等配置。这样后续维护起来方便。# 文件路径config.py import os # 从环境变量读取 API Key避免写死在代码里 API_KEY os.getenv(LLM_API_KEY, ) BASE_URL os.getenv(LLM_BASE_URL, https://api.openai.com/v1) API_MODEL gpt-4o-mini EMBEDDING_MODEL text-embedding-3-small # 本地向量索引保存路径 VECTOR_STORE_DIR ./vector_store # 原始资料目录 DATA_DIR ./data # 文档切分参数 CHUNK_SIZE 500 CHUNK_OVERLAP 50 # 检索返回的文档块数量 TOP_K 3这里特别强调一下 API Key 的管理。不要直接把真实 Key 写进代码或提交到 Git 仓库。推荐的做法是设置环境变量或者使用.env文件并且把.env加入.gitignore。4.3 编写文档加载与切分模块加载模块负责读取原始文件。为了简单这里先以纯文本文件为例。实际项目中你可能需要支持 PDF、Word、Markdown 等格式。加载 PDF 时可以使用pypdf或pymupdf加载 Word 时可以使用python-docx。# 文件路径src/loader.py def load_document(file_path: str) - str: 加载文本文件内容。 实际项目中可以根据扩展名选择不同的解析器。 with open(file_path, r, encodingutf-8) as f: return f.read()切分模块是整个流程里容易被忽略但非常重要的环节。切分太大检索时噪声多切分太小段落语义不完整。这里提供一个按字符数切分并带重叠区域的实现。# 文件路径src/splitter.py def split_text(text: str, chunk_size: int 500, overlap: int 50) - list[str]: 将长文本切分成多个块块之间保留 overlap 个字符的重叠。 重叠区域可以避免语义在切分边界被截断。 chunks [] start 0 while start len(text): end start chunk_size chunk text[start:end] if chunk: chunks.append(chunk) if end len(text): break start end - overlap return chunks这种简单的切分方式适合演示。工程化时你可以考虑按标题、段落、句子结构来做智能切分尤其是 Markdown 和论文这类结构化文档。4.4 编写向量化与检索模块检索模块要做两件事把文档块转成向量根据用户问题召回最相关的块。大部分向量数据库提供了相似的 API插入、查询、持久化。这里我用一个抽象版本展示思路。你可以把它替换成 Chroma、FAISS、Milvus、Qdrant 等具体实现。# 文件路径src/retriever.py from config import EMBEDDING_MODEL, TOP_K class VectorStore: def __init__(self, api_key: str): # 实际项目中这里会连接向量数据库 # 示例中我们用一个列表模拟 self.vectors [] self.texts [] self.api_key api_key def add_documents(self, docs: list[str]): 将文档转成向量并存储。 这里的关键是调用 Embedding API。 for doc in docs: vector self._get_embedding(doc) self.vectors.append(vector) self.texts.append(doc) def query(self, question: str, top_k: int TOP_K) - list[str]: 将问题转成向量然后召回最相似的文档块。 question_vector self._get_embedding(question) scored [] for i, vector in enumerate(self.vectors): score self._cosine_similarity(vector, question_vector) scored.append((score, i)) scored.sort(keylambda x: x[0], reverseTrue) return [self.texts[i] for _, i in scored[:top_k]] def _get_embedding(self, text: str): # 该函数应调用 Embedding API 或本地 embedding 模型 # 返回一个向量例如 list[float] raise NotImplementedError(请根据你的 Embedding 服务实现) def _cosine_similarity(self, vec1, vec2): raise NotImplementedError(请根据向量表示实现余弦相似度计算)请注意上面代码里的两个raise NotImplementedError是需要你根据自己的 Embedding 服务补全的。如果你使用在线 Embedding API一般是这样def _get_embedding(self, text: str): import requests response requests.post( f{BASE_URL}/embeddings, headers{Authorization: fBearer {self.api_key}}, json{model: EMBEDDING_MODEL, input: text} ) response.raise_for_status() return response.json()[data][0][embedding]如果你使用本地模型比如sentence-transformers则会是另一种写法。余弦相似度计算也比较标准import math def _cosine_similarity(self, vec1, vec2): dot sum(a * b for a, b in zip(vec1, vec2)) norm1 math.sqrt(sum(a * a for a in vec1)) norm2 math.sqrt(sum(b * b for b in vec2)) if norm1 0 or norm2 0: return 0.0 return dot / (norm1 * norm2)这样你就有了一个最核心的检索模块。真正工程化时我会建议直接用成熟的向量数据库而不是自己维护列表。但对于理解原理这个版本足够清晰。4.5 编写生成模块生成模块负责把检索到的上下文拼装成提示词然后调用大模型生成回答。提示词的质量决定了回答的质量。# 文件路径src/generator.py from config import API_MODEL, BASE_URL class LLMGenerator: def __init__(self, api_key: str): self.api_key api_key self.base_url BASE_URL self.model API_MODEL def generate(self, question: str, contexts: list[str]) - str: prompt self._build_prompt(question, contexts) # 这里调用对话补全接口 # 为了演示用 requests 实现一个简化版本 import requests response requests.post( f{self.base_url}/chat/completions, headers{Authorization: fBearer {self.api_key}}, json{ model: self.model, messages: [ {role: system, content: 你是一个研究助手请根据给定的参考资料回答问题。回答要简洁、准确并注明信息来源。}, {role: user, content: prompt} ] } ) response.raise_for_status() return response.json()[choices][0][message][content] def _build_prompt(self, question: str, contexts: list[str]) - str: context_text \n\n---\n\n.join(contexts) return f请根据下面的参考资料回答用户问题。 参考资料 {context_text} 用户问题 {question} 回答要求 1. 如果参考资料无法回答问题请直接说明“根据现有资料无法回答”。 2. 回答中请标注关键信息来自哪个参考资料。 3. 不要编造参考资料中不存在的信息。这里的关键点有两个。第一提示词里给模型划定了回答边界要求它不能凭空回答。这能大幅降低“幻觉”问题。第二把多个上下文块拼在一起时要有清晰的分隔标识方便模型区分不同来源。4.6 主流程串联最后用run.py把这个流程串起来。# 文件路径run.py import os from config import API_KEY, DATA_DIR, CHUNK_SIZE, CHUNK_OVERLAP from src.loader import load_document from src.splitter import split_text from src.retriever import VectorStore from src.generator import LLMGenerator def main(): if not API_KEY: print(请先设置 LLM_API_KEY 环境变量) return # 1. 加载并切分文档 paper_path os.path.join(DATA_DIR, sample_paper.txt) raw_text load_document(paper_path) chunks split_text(raw_text, CHUNK_SIZE, CHUNK_OVERLAP) print(f切分完成共 {len(chunks)} 个文本块) # 2. 建立向量索引 store VectorStore(api_keyAPI_KEY) store.add_documents(chunks) print(向量索引建立完成) # 3. 检索并生成 question 这篇论文提出的方法是什么 contexts store.query(question) generator LLMGenerator(api_keyAPI_KEY) answer generator.generate(question, contexts) print(回答) print(answer) if __name__ __main__: main()4.7 运行与验证准备一份测试文本data/sample_paper.txt内容可以是任意一段技术描述。然后运行export LLM_API_KEY你的APIKey python run.py预期输出分几步切分完成共 12 个文本块 向量索引建立完成 回答 该论文提出的核心方法主要是……如果检索结果不太相关建议先检查CHUNK_SIZE和TOP_K这两个参数。检索不精准时可以调大TOP_K上下文太长时可以调小CHUNK_SIZE。4.8 结果说明从这个小示例中你可以清楚地看到 RAG 的完整链路文档加载负责读取资料文档切分决定检索的基本单元向量化把文本变为可计算的向量检索找出最相关的文本块生成把相关文本块交给 LLM产出有依据的回答。这个链路就是各种“知识库问答”“文档助手”的核心骨架。后面不管换什么框架、什么向量数据库本质逻辑都是这样的。5. 个人知识库实战Obsidian LLM Wiki 工作流热词里经常能看到“Obsidian LLM Wiki 搭建个人知识库”。顺着上面的 RAG 思路我们完全可以自己搭建一个轻量级的个人知识库系统。5.1 什么是 LLM Wiki 范式“LLM Wiki”这个概念核心思想是把个人笔记库当作一个可以“对话”的 Wiki。传统的 Wiki 靠人工整理目录和链接而 LLM Wiki 则让你直接用自然语言提问系统自动从笔记中检索相关内容并给出回答。这个范式很适合作研究笔记因为它解决了两个痛点笔记写完之后很难被再次找到笔记之间缺少语义关联关键词搜索覆盖不全。配合 Obsidian 这类本地 Markdown 笔记工具你的每篇笔记本身就是一个信息单元。我们可以用一个 Python 脚本把这些 Markdown 文件全部扫描、切分、向量化然后提供问答接口。5.2 扫描本地 Markdown 笔记并生成向量索引下面给出一个简化版的脚本思路。它做三件事扫描目录下的.md文件切分内容生成向量索引并保存。# 文件路径build_index.py import os import glob from config import DATA_DIR, EMBEDDING_MODEL def scan_markdown_files(root_dir: str) - list[tuple[str, str]]: 返回 [(文件相对路径, 文件内容), ...] results [] for file_path in glob.glob(os.path.join(root_dir, **, *.md), recursiveTrue): with open(file_path, r, encodingutf-8) as f: content f.read() rel_path os.path.relpath(file_path, root_dir) results.append((rel_path, content)) return results def build_index(): notes scan_markdown_files(./notes) all_chunks [] metadatas [] for rel_path, content in notes: # 这里可以复用之前写好的 split_text chunks split_text(content, 300, 30) for chunk in chunks: all_chunks.append(chunk) metadatas.append({source: rel_path}) print(f扫描到 {len(notes)} 个笔记文件切分成 {len(all_chunks)} 个文本块) # 将 all_chunks 向量化并保存到本地向量库 # 工程化时建议使用 Chroma / FAISS / LanceDB 等 # 这里先打印出前几个块方便你确认效果 for i, chunk in enumerate(all_chunks[:3]): print(f--- chunk {i} ---) print(chunk[:100]) if __name__ __main__: build_index()实际工程化时你可以把all_chunks和metadatas一起写入向量数据库。每个文本块都要记录它来自哪个文件这样回答时可以带上来源路径。5.3 增加“引用来源”的回答格式在研究场景中引用来源非常重要。无论你是基于 RAG 做问答还是基于 Agent 做报告都应该让回答附带来源。实践中我习惯在提示词里明确要求模型引用编号然后在后端把编号映射成文件路径。def format_citations(contexts: list[str], metadatas: list[str]) - str: 为每个上下文块编号并标注来源。 blocks [] for idx, (text, source) in enumerate(zip(contexts, metadatas)): blocks.append(f[{idx 1}] 来源: {source}\n{text}) return \n\n.join(blocks)这样的回答格式在阅读时能快速回溯原文非常实用。6. 从 RAG 到 Agent为什么需要编排框架当你把 RAG、工具调用、多轮记忆、任务规划组合到一起时代码会越来越复杂。这时候就轮到“编排框架”登场。热词里有“llm 应用为什么需要编排框架”这确实是一个值得思考的问题。让我用一个例子来解释。假设你要实现一个文献调研助手它需要根据研究主题生成检索关键词调用学术搜索 API 搜索论文下载和解析 PDF把论文内容写入向量库最后生成综述报告。如果不用编排框架你需要自己管理每一步的状态、错误处理、重试、上下文的拼接。代码会变成一串长长的函数调用链。而编排框架的价值就是把这套流程抽象成可配置、可维护的模块。6.1 Python 生态与 Java 生态的典型选择在 Python 生态中LangChain 和 LlamaIndex 是比较常见的框架。它们提供了文档加载器、文本切分器、向量库封装、Agent 工具调用等模块能显著降低开发成本。在 Java 生态中Spring AI 是一个值得关注的选择。它借鉴了 Spring 的模块化思想把模型接入、向量存储、工具调用都做成了可配置组件适合已经有 Spring Boot 后端的团队。MCP 也值得了解。它是一个模型上下文协议用于让模型之间、模型与工具之间、应用之间以标准化方式交换上下文。当你需要把多个能力组合成复杂应用时类似 MCP 这样的标准化协议可以减少“胶水代码”。6.2 一个配置化工作流的简化示例下面是一个 YAML 风格的配置片段用来表示一个简单的调研工作流定义。它之所以用 YAML 而不是代码是因为工程上我们希望把流程定义和业务逻辑分离。# 文件路径research_workflow.yaml workflow: name: literature_review steps: - name: generate_query type: llm prompt: 根据用户研究主题生成3个搜索关键词 - name: search_papers type: tool tool: academic_search_api params: query: {{steps.generate_query.output}} - name: download_and_parse type: tool tool: pdf_parser params: urls: {{steps.search_papers.output}} - name: summarize type: llm prompt: 对每篇论文生成结构化摘要 - name: write_review type: llm prompt: 根据所有摘要生成综述报告这个配置展示了编排框架的一个核心思想让流程步骤成为可配置的数据让每一步的输出成为下一步的输入。这样你可以快速调整流程而不用改大量业务代码。在实际项目中我建议先把一个最简流程跑通再逐步添加工具和分支逻辑。一开始就设计复杂的 Agent 图很容易让项目失控。7. 常见问题与排查思路在搭建 LLM 研究工具的过程中很多问题都是有规律可循的。这里整理一份高频问题排查表。问题现象常见原因解决思路调用向量 API 时提示“文本向量 API 未配置”没有设置 API Key 或配置的模型名错误检查环境变量、配置文件确认向量模型名是否可用本地跑模型显存溢出加载精度过高比如直接用 fp32改用 fp16 或 bf16必要时使用量化版本检索结果完全不相关切分太大导致语义混杂或向量模型不匹配调小 chunk size增加 overlap检查 embedding 模型是否与查询语言一致回答出现编造内容上下文中缺少足够信息模型只能“猜”在 Prompt 中明确要求“无依据时拒绝回答”并增加检索召回数量上下文太长超出模型限制召回的文本块过多或单块太长减少 TOP_K调小 chunk size优先使用摘要作为上下文响应速度很慢模型参数大、GPU 性能不足或网络延迟尝试小模型、降低精度、对运行环境做性能测试Agent 工作流卡在某个工具调用上工具入参不符合 API 要求检查工具定义、参数映射与日志同一套代码在不同机器效果不一致依赖版本、模型版本或精度配置不同锁定版本记录环境差异使用配置文件统一参数另一个在我实际开发中经常出现的问题是把本地文件全部加载后直接让模型读。这种做法在小项目里可行但一旦文件增多不仅上下文占用大回答质量也会下降。RAG 就是用来解决这个问题的但很多人第一次使用 RAG 时忽略了“切分质量”。切分质量直接影响检索效果。切分过细一个完整方法描述可能被拆成两半切分过粗每个块里包含太多无关信息检索的精确度下降。我的经验是先观察 2-3 个典型查询的召回结果再针对性调整切分参数而不是一上来就追求复杂的切分算法。8. 最佳实践与工程建议最后这部分我想结合研究场景给出一套比较务实的工程建议。这些建议不针对某一个具体框架而是适用于大部分 LLM 应用项目。8.1 简单优先先用最小的方案跑通很多人在初期容易陷入“框架焦虑”还没跑通最简问答就在纠结要不要上 Agent、要不要上编排框架。我的建议是分阶段推进先用在线对话工具验证 Prompt 思路然后写一个最小脚本实现 RAG 链路再考虑引入框架和向量数据库最后才根据需求加上 Agent 编排。每一步都建立在前一步的可运行成果之上。这样出现问题容易定位开发体验也好很多。8.2 做好提示词版本管理研究场景中的 Prompt 往往需要频繁调试。Prompt 也是代码应该纳入项目管理。建议在项目里单独建一个prompts/目录每个模板一个文件并在文件头部写明用途、输入输出格式、修改日期。prompts/ ├── summary.md ├── literature_review.md ├── code_explainer.md └── qa_with_context.md这样可以避免“改着改着忘了之前版本的效果”这种尴尬情况。8.3 重视数据隐私与合规边界在研究工作中有些资料可能是未公开的论文、项目计划书、内部文档。使用在线 LLM API 时这些数据会发送给服务商。建议做如下分级公开资料可以使用在线 API内部数据使用本地模型或在合规的私有化环境中调用敏感数据强烈建议在本地推理引擎中运行并严格限制访问权限。不要因为贪图方便把敏感数据直接送入在线服务。这不仅是合规问题更是对自己研究负责的基本要求。8.4 关注可观测性与日志LLM 应用有一个特点同样的输入输出可能每次都不一样。因此可观测性非常重要。建议至少记录以下信息用户问题最终使用的 Prompt检索到的上下文块及各自来源模型返回内容耗时与 token 消耗调用的模型版本与参数。有了这些日志你才能在问题出现时复现和定位。否则一句“我昨天还能用今天就不行了”会把你带入漫长的猜测中。8.5 安全边界与最小权限如果你在项目中集成了数据库查询、代码执行等工具一定要遵循最小权限原则。当 Agent 可以调用工具时它不应该拥有比你更高的权限。具体来说数据库账号只授予必要的 SELECT 权限代码执行工具运行在沙箱中删除、更新等危险操作需要人工二次确认对外发布的接口要做访问认证和限流。这些原则听起来是后端常识但在 LLM Agent 场景中往往容易被忽略。一个自主规划并调用工具的 Agent如果没有权限边界风险会被明显放大。8.6 预留人工审核环节研究场景里LLM 的输出不能直接当作最终结论。不管是用 RAG 做文献综述还是用 Agent 做数据调研都要有人工审核环节。这也是我认为在研究场景中使用 LLM 最重要的一条建议。你可以让 LLM 生成初稿但要在流程上设计“人工确认”节点。比如输出报告前必须由研究者检查引用来源删除有疑虑的段落修正不准确的信息。真正的效率提升来自“人机协作”而不是把判断权完全交给模型。9. 总结与后续学习方向从一个社区提问开始我们从概念到代码把 LLM 在研究场景中的应用方式梳理了一遍。这篇文章里你应该已经掌握了几个关键内容LLM 在研究场景中的四个应用层次问答摘要、结构化抽取、RAG 知识库、Agent 工作流本地推理中 fp16、fp32、bf16 精度问题的基本概念和选择思路一个最小可运行的 RAG 检索问答系统的完整代码和运行流程基于 Obsidian LLM Wiki 思路的个人知识库搭建方法编排框架的价值以及常见问题排查和工程化建议。下一步如果你想继续深入可以根据自己的兴趣选择一个方向如果你想强化工程能力可以深入研究 LangChain、LlamaIndex 或 Spring AI 的源码如果你想优化检索质量可以学习向量数据库的原理以及分块策略的进阶方法如果你想做 Agent 应用可以从一个简单的工具调用开始逐步增加任务规划如果你关心模型运行效率可以继续学习量化、推理引擎、混合精度训练等底层知识。在实际项目中我建议你先从一个不超过 50 篇文档的小型知识库开始。把数据准备好跑通 RAG 链路然后观察真实查询的效果再逐渐扩大规模。LLM 生态发展很快但只要把基础概念和工程习惯打牢无论工具怎么变你都能快速迁移。如果这篇文章对你有帮助建议收藏备用。你也可以顺着其中的某一节亲手跑一个最小示例那会比只看文章收获大得多。