企业官网建设流程全解析

大家好，今天我们来聊一个很有意思、也很实际的问题。

在技术社区里，经常能看到这样一类提问：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 编排、工具调用等多个方向。传统的做法可能是：

1. 在搜索引擎里输入关键词，逐个打开页面；
2. 下载十几篇论文或技术文章；
3. 边读边做笔记，最后再汇总；
4. 把重要结论整理成自己的知识体系。

这个过程非常耗时，而且很容易出现“读了很多资料，但真正内化到知识库里的内容很少”的情况。问题不在于阅读速度，而在于信息筛选和结构化的效率太低。

LLM 正好能在这几个环节帮上忙：

• 信息压缩：把几页论文摘要成几百字要点；
• 定向抽取：按你定义的字段，从多篇文档里提取结构化信息；
• 语义检索：用自然语言去查资料，而不是靠关键词精确匹配；
• 内容生成：根据检索结果生成综述初稿、对比表格、技术方案；
• 代码辅助：解释论文里的公式、把算法伪代码改写成 Python 实现。

要注意，LLM 不是学术搜索引擎。它不能保证引用的真实性，也不能替代原文阅读。它的价值更像一个“助理”，帮你把前期工作尽量压缩，但最终的判断仍然要由你自己完成。

1.2 从对话到研究工具：几个容易混淆的概念

在开始实操之前，有几个概念需要区分清楚，否则后面看代码会有点懵：

这些概念在研究工作流里通常是配合使用的。

比如最基础的“LLM 问答”，只是把问题发给模型，模型直接回答。这种方式适合常识性问题，但不适合回答“你本地那 200 篇论文里有什么结论”，因为模型没有见过这些资料。

于是就有了 RAG。RAG 把“检索”和“生成”结合在一起：先从你的资料库中检索出相关的段落，再把这些段落作为上下文交给 LLM 生成回答。这样回答就有据可查。

再进一步，如果把这个流程拆成多个步骤，让 LLM 决定“先查什么、再查什么、用什么工具去查”，那就是 Agent。Agent 适合更复杂的任务，比如综合多个数据源做调研报告。

2. 常见应用模式：研究流程中的 LLM 使用方式

从我和身边开发者的实践来看，LLM 在研究中的应用基本可以分成四个层次。你可以根据自己的需求选择从哪一档切入。

2.1 一次性问答与快速摘要

这是最简单的一种模式，适合处理“一两篇文章”级别的输入。

比如你拿到一篇 PDF 论文，直接拖动到支持长上下文的对话工具中，然后问：

• 这篇论文要解决什么问题？
• 核心方法是什么？
• 实验结论怎么样？
• 有哪些局限性？

这种方式成本低、上手快，不需要写代码。缺点是无法积累成知识库，每次都要重复操作，而且当资料变多、上下文超过限制时，模型会遗忘前文。

2.2 结构化信息抽取

比问答更进阶一点的是结构化抽取。你可以让 LLM 按固定格式输出论文信息，比如：

• 标题
• 作者
• 发表年份
• 解决的问题
• 使用的方法
• 实验数据集
• 主要结论
• 局限性

把多篇论文交给模型，让模型批量生成这样的卡片，再统一归档。这种方式非常适合写文献综述的前期准备。

结构化抽取的关键是给出明确的输出模板。模板越具体，输出越稳定。你可以用 JSON 格式来定义模板，方便后续程序处理。

2.3 基于 RAG 的知识库问答

当资料量从几篇增长到几十、几百篇时，一次性把全文塞给模型就不太现实了。一方面受到上下文窗口限制，另一方面成本也会增加。

RAG 是这一阶段最常用的方案。它的基本思路是：

1. 把所有文档切分成小块；
2. 将每一块转换成向量（Embedding）；
3. 把向量存储到向量数据库中；
4. 用户提问时，把问题也转换成向量；
5. 从向量库中召回最相关的若干块；
6. 将这些块作为上下文，连同用户问题一起交给 LLM 生成回答。

RAG 最大的优点是可扩展、可追溯。资料更新时只需要增量更新向量库，回答时可以引用具体段落来源。

2.4 基于 Agent 的多步骤工作流

如果任务不是“回答一个问题”，而是“完成一项调研”，那 Agent 就更有优势。

例如：帮我调研一下最近三个月关于“检索增强生成（RAG）在金融领域的应用”的论文，输出一份综述。

Agent 可以自己拆解步骤：

1. 查找关键词；
2. 搜索论文数据库；
3. 对结果去重和过滤；
4. 逐个摘要；
5. 综合成报告。

这个过程中可能涉及搜索引擎调用、数据库查询、代码执行等多种工具。Agent 的核心价值在于编排，而不是“更聪明的回答”。

下表可以帮你快速定位自己需要哪个层次：

3. 环境准备与精度问题：本地跑 LLM 必须知道的事

如果你只想用现成的在线服务，环境准备很简单。但如果你想在自己机器上跑模型、搭知识库，那么环境、精度、显存这几个问题绕不开。尤其是“精度”这个问题，很多初学者在这里栽跟头。

3.1 三条技术路线怎么选

按照项目阶段和使用场景，我一般把环境准备分成三条路线：

路线一：纯在线服务

适合刚开始学习、对数据隐私没有特别要求的情况。只需要注册 API Key，通过 HTTP 接口调用模型。优势是省事，劣势是敏感数据不能进。

路线二：本地推理引擎

适合离线环境、数据敏感、或者想深入理解模型运行的场景。需要准备 GPU 或性能较好的 CPU，安装推理引擎，下载模型文件。这里会接触到精度和量化问题。

路线三：在线 API + 本地框架结合

这是目前我比较推荐的项目落地方式。在线 API 负责大模型推理，本地框架负责资料管理、检索、编排。这样既能用到较强的基础模型，又能控制敏感数据的流向，同时代码逻辑完全掌握在自己手里。

版本说明：由于 LLM 生态迭代非常快，不同的框架、工具、模型版本之间可能存在兼容性问题。本文示例以常见环境为例，重点演示配置思路。你实际使用时应根据项目版本调整依赖，不要盲目复制版本号。

3.2 fp16、fp32、bf16：LLM 精度问题详解

这是一个很容易被忽略，但实际开发中影响很大的知识点。

LLM 的权重和中间计算都需要用浮点数表示。浮点数的“精度”直接决定了模型能否稳定推断，也决定了显存占用和计算速度。常见的有三种格式：

在 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 均可；
• Python：3.9 或以上；
• 包管理工具：pip 或 conda；
• 运行时：在线 API 需要一个可用的 API Key；本地推理需要安装推理引擎、下载模型文件；
• 向量存储：可以使用开源向量库，或者直接用内存中的向量索引做小规模实验；
• 界面工具：如果只写脚本，终端就够用；如果要做成工具，可以用 gradio 或 streamlit。

下面是一个 requirements.txt 的示例。它只是一个参考结构，具体版本请按你的实际环境调整。

# 文件路径：requirements.txt # 注意：版本号仅作示意，请根据实际环境安装 openai>=1.0.0 langchain>=0.1.0 chromadb>=0.4.0 pypdf>=3.17.0 python-dotenv>=1.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.py

• data目录放原始资料；
• 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", encoding="utf-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(key=lambda x: x[0], reverse=True) 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": f"Bearer {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": f"Bearer {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_key=API_KEY) store.add_documents(chunks) print("向量索引建立完成") # 3. 检索并生成 question = "这篇论文提出的方法是什么？" contexts = store.query(question) generator = LLMGenerator(api_key=API_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 则让你直接用自然语言提问，系统自动从笔记中检索相关内容并给出回答。

这个范式很适合作研究笔记，因为它解决了两个痛点：

1. 笔记写完之后很难被再次找到；
2. 笔记之间缺少语义关联，关键词搜索覆盖不全。

配合 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"), recursive=True): with open(file_path, "r", encoding="utf-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 应用为什么需要编排框架”，这确实是一个值得思考的问题。让我用一个例子来解释。

假设你要实现一个文献调研助手，它需要：

1. 根据研究主题生成检索关键词；
2. 调用学术搜索 API 搜索论文；
3. 下载和解析 PDF；
4. 把论文内容写入向量库；
5. 最后生成综述报告。

如果不用编排框架，你需要自己管理每一步的状态、错误处理、重试、上下文的拼接。代码会变成一串长长的函数调用链。而编排框架的价值，就是把这套流程抽象成可配置、可维护的模块。

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 研究工具的过程中，很多问题都是有规律可循的。这里整理一份高频问题排查表。

另一个在我实际开发中经常出现的问题是：把本地文件全部加载后直接让模型读。这种做法在小项目里可行，但一旦文件增多，不仅上下文占用大，回答质量也会下降。RAG 就是用来解决这个问题的，但很多人第一次使用 RAG 时忽略了“切分质量”。

切分质量直接影响检索效果。切分过细，一个完整方法描述可能被拆成两半；切分过粗，每个块里包含太多无关信息，检索的精确度下降。我的经验是：先观察 2-3 个典型查询的召回结果，再针对性调整切分参数，而不是一上来就追求复杂的切分算法。

8. 最佳实践与工程建议

最后这部分，我想结合研究场景，给出一套比较务实的工程建议。这些建议不针对某一个具体框架，而是适用于大部分 LLM 应用项目。

8.1 简单优先，先用最小的方案跑通

很多人在初期容易陷入“框架焦虑”：还没跑通最简问答，就在纠结要不要上 Agent、要不要上编排框架。我的建议是分阶段推进：

1. 先用在线对话工具验证 Prompt 思路；
2. 然后写一个最小脚本实现 RAG 链路；
3. 再考虑引入框架和向量数据库；
4. 最后才根据需求加上 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 生态发展很快，但只要把基础概念和工程习惯打牢，无论工具怎么变，你都能快速迁移。

如果这篇文章对你有帮助，建议收藏备用。你也可以顺着其中的某一节，亲手跑一个最小示例，那会比只看文章收获大得多。