企业官网建设流程全解析

1. 这不是口号，是今天真实的技术现场

“你没有任何借口不成为大语言模型开发者”——这句话乍听像极了某场科技大会上的激情演讲，但如果你过去三个月里真正泡在 GitHub、Hugging Face 和本地 Jupyter Notebook 里调过模型、改过提示词、跑过微调脚本，你就会发现：它不是鼓动，而是陈述事实。我从去年底开始系统性地把 LLM 开发能力嵌入到日常工作中，从自动化客户邮件初稿生成，到为内部知识库构建 RAG 检索增强问答系统，再到用 LoRA 微调一个 7B 模型适配垂直领域合同审查任务。整个过程没有动用任何私有 GPU 集群，主力设备是一台 2021 款 MacBook Pro（M1 Pro，16GB 统一内存），外加每月不到 $20 的云上推理 API 调用预算。这不是“理论上可行”，而是我每天打开终端就能复现的流水线。核心关键词——LLM 开发者、零门槛启动、本地小模型、提示工程、轻量微调、RAG 架构、消费级硬件适配——全部落在真实可触摸的操作层。它适合三类人：想摆脱“只会调 API”的工具使用者、正在寻找第二技能曲线的非算法岗工程师（前端/后端/测试/产品）、以及希望用技术手段解决具体业务问题但从未写过一行 PyTorch 的业务专家。它不承诺让你立刻写出 Llama 3，但它能确保你在 48 小时内，用自己的笔记本跑通一个能回答你公司内部 FAQ 的、带记忆和引用溯源的对话机器人。这背后没有魔法，只有被大幅压缩的技术纵深、被标准化的开发范式，以及一批真正愿意把“复杂”翻译成“可执行步骤”的开源项目。

2. 为什么说“没借口”？——技术栈塌方与开发范式迁移

2.1 技术栈的“三重塌方”：算力、模型、工具链

所谓“没借口”，首先源于支撑 LLM 开发的三大支柱发生了根本性位移，不再是高耸入云的壁垒，而成了可踩踏的台阶。

第一重塌方是算力获取方式的平民化。五年前，“训练大模型”等于“租用 A100 集群+百万级预算”，今天，“本地运行 7B 级别模型进行推理”已成标配。关键转折点是 Apple Silicon 的统一内存架构与 Metal Performance Shaders（MPS）后端的成熟。以 llama.cpp 为例，它通过纯 C/C++ 实现量化推理，绕过 Python 生态的开销，在 M1/M2/M3 Mac 上，Q4_K_M 量化后的 Phi-3-mini（3.8B）模型，单次响应延迟稳定在 800ms 内，内存占用压在 2.1GB；而 Qwen2-0.5B 在 iPhone 15 Pro 上也能流畅流式输出。这不是“能跑”，而是“跑得稳、等得起”。对比之下，云 API（如 OpenRouter 或 Together.ai）虽省事，但存在响应抖动、上下文长度限制、敏感数据外泄风险——而本地运行，你手里的键盘敲下的每一个 token，都只经过你自己的 CPU/GPU。我实测过：处理一份 12 页的 PDF 合同摘要，本地 Qwen2-1.5B + llama.cpp 耗时 22 秒；同等内容走云端 API，平均耗时 3.8 秒，但失败率高达 17%（超时或 token 超限），且每次请求都需网络握手。算力不再稀缺，稀缺的是对本地化部署的意识。

第二重塌方是模型供给的“超市化”。Hugging Face 不再是学术论文的附录链接，而是真正的模型超市。过去一年，社区涌现出大量“为开发者而生”的模型：Phi-3 系列（微软）专为边缘设备优化，参数少、推理快、指令遵循强；Gemma-2（Google）提供 2B/27B 双版本，文档极其详尽，连如何用 Ollama 加载都写进 README；Qwen2（通义千问）则在中文长文本理解上表现突出，且官方直接发布 GGUF 量化格式。更重要的是，这些模型全部开放商用许可（Apache 2.0 或 MIT），无隐藏条款。我曾为一家律所定制合同风险点识别工具，直接选用 Qwen2-1.5B-Instruct，仅用 3 天就完成提示词设计+本地部署+初步测试。如果换成闭源模型，光是商务谈判和合规审核流程，就足以拖垮整个项目周期。模型不再是“黑箱资产”，而是“即插即用的模块”。

第三重塌方是工具链的“乐高化”。十年前做 NLP，你要从分词器、Embedding 层、RNN/LSTM 构建开始；今天，一个 LLM 开发工作流，已被拆解为可自由组合的标准化积木：

• 加载与推理：llama.cpp（C/C++，极致轻量）、Ollama（CLI 友好，一键拉取）、Text Generation WebUI（图形界面，支持多卡）；
• 提示工程：LangChain（编排复杂链路）、LlamaIndex（专注 RAG 数据管道）、DSPy（用声明式语法约束模型行为）；
• 微调：Unsloth（加速 LoRA 训练，M2 Mac 上 7B 模型微调 1 小时可出效果）、Axolotl（配置驱动，YAML 定义全流程）；
• 评估：RAGAS（自动评估检索+生成质量）、DeepEval（支持自定义指标）。
  这些工具不再要求你精通反向传播，而是像搭积木一样，用 YAML 配置文件定义数据路径、模型路径、量化参数。我给一位做跨境电商的运营同事培训时，她第一天学会用 Ollama run qwen2:1.5b，第二天就用 LangChain 写出自动解析买家差评并生成客服回复草稿的脚本——全程未接触任何 PyTorch 代码。工具链的抽象层级，已从“写模型”下沉到“写逻辑”。

2.2 开发范式的本质迁移：从“模型为中心”到“任务为中心”

“没借口”的深层原因，是开发重心的根本转移。过去十年，AI 工程师的核心竞争力是“调参能力”——如何让 ResNet-50 在 ImageNet 上多刷 0.2% 准确率；今天，LLM 开发者的护城河，是“任务拆解能力”——如何把“让销售团队快速掌握新产品话术”这个模糊需求，精准映射为：

1. 构建产品知识图谱（用 LlamaIndex 从 PDF/Notion 导入）；
2. 设计多跳检索策略（先查“适用场景”，再关联“竞品对比”）；
3. 编写带角色约束的提示词（“你是一名有 5 年经验的 SaaS 销售总监，用不超过 3 句话向 CTO 解释本产品与 Snowflake 的差异”）；
4. 加入事实核查机制（强制模型在回答后标注引用来源 chunk ID）。

这个过程，90% 的时间花在理解业务、设计数据流、打磨提示词，而非调整学习率或 dropout 率。我参与过三个企业级 RAG 项目，最耗时的环节永远是：和业务方一起梳理“用户到底会问什么”，然后手工标注 200 条典型 query → answer 对，用于验证检索召回率。技术实现本身，用 LlamaIndex + Qwen2-1.5B，三天内即可交付 MVP。这意味着，一个熟悉业务逻辑的产品经理，只要愿意花一周时间学习 LangChain 基础语法和提示词设计原则，就能主导一个中等复杂度的 LLM 应用落地。技术门槛的消失，本质是问题定义权的回归——开发者终于可以直面真实世界的问题，而不是被困在模型性能的迷宫里。

2.3 “借口”的幻觉来源：被放大的认知偏差

现实中，人们常提出的“借口”，其实都源于对当前技术现实的误判：

• “我没有 GPU” → 忽略了 llama.cpp 在 CPU/Metal 上的成熟度，也忽略了 Q4 量化后 7B 模型在 16GB 内存设备上的稳定表现；
• “模型太难懂” → 混淆了“理解 Transformer 架构”和“使用预训练模型完成任务”，后者只需掌握输入/输出格式与基本提示原则；
• “不知道从哪开始” → 源于信息过载，而非路径缺失。事实上，Hugging Face 提供了从“Hello World”到“生产部署”的完整学习路径，且所有教程均基于真实可运行的 Colab Notebook；
• “怕学完就过时” → LLM 领域迭代快是事实，但核心范式（RAG、LoRA 微调、提示工程）已稳定超过 18 个月，底层变化不影响上层应用逻辑。

我曾统计过自己过去半年写的 47 个 LLM 相关脚本，其中 39 个基于 llama.cpp + LangChain 组合，8 个用 Ollama + 自定义 API 封装。所有脚本至今仍可运行，仅需更新模型名称或调整少量提示词。技术债远低于传统 Web 开发——因为你的代码不依赖框架的某个特定版本，而依赖的是模型的输入/输出契约，这个契约异常稳定。

3. 从零到第一个可运行 LLM 应用：手把手实战路径

3.1 第一步：环境准备——5 分钟建立本地推理能力

不要下载 Anaconda，不要配置 CUDA，不要碰 Docker。最简路径就是：Ollama + VS Code。这是我在给零基础学员做入门培训时，验证过 100% 成功率的组合。

1. 安装 Ollama：访问 https://ollama.com/download ，下载对应 macOS/Windows/Linux 的安装包。安装过程无任何选项，双击即完成。安装后，终端输入ollama --version，返回版本号即成功。
2. 拉取首个模型：在终端执行ollama run qwen2:1.5b。Ollama 会自动从 Hugging Face 拉取 Qwen2-1.5B 的 GGUF 量化版本（约 1.2GB），全程无需手动下载或转换。拉取完成后，你会进入一个交互式聊天界面，输入你好，模型会即时回复。这就是你的第一个 LLM 应用——它已在你本地运行，不联网、不传数据、无延迟。
3. 集成到 VS Code：安装 VS Code 插件 “Ollama”（作者：juliosueiras）。重启后，按Cmd+Shift+P（Mac）或Ctrl+Shift+P（Win），输入 “Ollama: Chat”，选择qwen2:1.5b，即可在编辑器侧边栏开启聊天窗口。你可以直接粘贴一段代码，让它解释逻辑；也可以把一份会议纪要丢进去，让它生成待办清单。这步的意义在于：把 LLM 从“玩具”变成“日常协作者”，建立最直接的正反馈。

提示：首次运行若卡在 “pulling manifest” 步骤，请检查网络是否能访问 Hugging Face（国内用户可提前设置代理，但注意：此处代理仅用于下载模型文件，后续所有推理均在本地完成，与代理无关）。若持续失败，可手动下载 GGUF 文件（搜索 “Qwen2-1.5B-GGUF”），放入~/.ollama/models/blobs/目录，Ollama 会自动识别。

3.2 第二步：构建你的第一个 RAG 应用——用 20 行代码连接知识库

假设你有一份《公司内部报销政策 V3.2.pdf》，你想让新员工随时提问“差旅住宿标准是多少”，得到精准答案。这就是典型的 RAG（检索增强生成）场景。我们不用写爬虫、不建向量库、不调 API，用 LlamaIndex + Ollama 10 分钟搞定。

1. 准备环境：在终端执行

   pip install llama-index-core llama-index-readers-file llama-index-llms-ollama

   注意：只装这三个包，避免引入 LangChain 等重量级依赖。

2. 创建rag_app.py：

   import os from llama_index.core import VectorStoreIndex, SimpleDirectoryReader from llama_index.llms.ollama import Ollama # 1. 加载 PDF（将文件放在同目录下的 'data' 文件夹） documents = SimpleDirectoryReader("data").load_data() # 2. 初始化本地 LLM（必须与 Ollama 中运行的模型名一致） llm = Ollama(model="qwen2:1.5b", request_timeout=300) # 3. 构建索引（自动分块、嵌入、存入内存向量库） index = VectorStoreIndex.from_documents(documents, llm=llm) # 4. 创建查询引擎 query_engine = index.as_query_engine(llm=llm) # 5. 执行查询 response = query_engine.query("差旅住宿标准是多少？") print(response)

   将《报销政策.pdf》放入data文件夹，运行python rag_app.py。首次运行会触发 PDF 解析和向量化，耗时约 40 秒；后续查询均在 2 秒内返回，且答案会附带引用来源（如 “见第 3.1.2 条”）。

注意：LlamaIndex 默认使用text-embedding-3-small嵌入模型，但该模型需联网。为彻底离线，可替换为llama-index-embeddings-jinaai（需pip install llama-index-embeddings-jinaai），或更简单——直接用 Ollama 自带的嵌入能力：在初始化llm后添加embed_model = OllamaEmbedding(model_name="nomic-embed-text")，再传入index构造函数。nomic-embed-text是目前开源嵌入模型中速度与精度平衡最佳的选择，GGUF 格式下在 M1 上单次嵌入仅需 120ms。

3.3 第三步：升级为生产级服务——用 FastAPI 封装 API

当你的 RAG 脚本验证有效后，下一步是把它变成团队可用的服务。我们用 FastAPI，因为它轻量、自带文档、部署简单。

1. 安装依赖：

   pip install fastapi uvicorn python-multipart

2. 创建main.py：

   from fastapi import FastAPI, UploadFile, File, Form from llama_index.core import VectorStoreIndex, SimpleDirectoryReader from llama_index.llms.ollama import Ollama from tempfile import NamedTemporaryFile import os app = FastAPI(title="Internal Policy QA API") # 全局索引变量（实际生产中应持久化到磁盘） index = None @app.post("/upload") async def upload_pdf(file: UploadFile = File(...)): global index with NamedTemporaryFile(delete=False, suffix=".pdf") as tmp: content = await file.read() tmp.write(content) tmp_path = tmp.name # 重新加载文档并构建索引 documents = SimpleDirectoryReader(input_files=[tmp_path]).load_data() llm = Ollama(model="qwen2:1.5b", request_timeout=300) index = VectorStoreIndex.from_documents(documents, llm=llm) os.unlink(tmp_path) # 清理临时文件 return {"status": "success", "message": "PDF uploaded and indexed"} @app.post("/query") async def query_policy(question: str = Form(...)): if index is None: return {"error": "No document uploaded. Please POST to /upload first."} query_engine = index.as_query_engine() response = query_engine.query(question) return {"answer": str(response), "source_nodes": [n.node.text[:100] for n in response.source_nodes]} if __name__ == "__main__": import uvicorn uvicorn.run(app, host="0.0.0.0", port=8000)

3. 启动服务：

   python main.py

   访问http://localhost:8000/docs，你会看到自动生成的 Swagger UI 文档。上传 PDF，再发送 POST 请求到/query，即可获得结构化 JSON 响应。整个服务仅依赖 3 个 Python 包，内存占用峰值 < 1.8GB，可在 8GB 内存的树莓派上运行。

3.4 第四步：加入微调能力——用 Unsloth 在 M2 Mac 上微调 7B 模型

当你发现通用模型在特定任务上表现不佳（比如总是把“增值税专用发票”错写成“增值税普通发票”），就需要微调。Unsloth 让这件事变得像“训练一个 sklearn 分类器”一样简单。

1. 准备数据：创建data.jsonl，每行一个 JSON 对象：

   {"instruction": "将以下采购申请单中的发票类型标准化为'增值税专用发票'或'增值税普通发票'","input": "发票类型：专票","output": "增值税专用发票"} {"instruction": "将以下采购申请单中的发票类型标准化为'增值税专用发票'或'增值税普通发票'","input": "需要普票","output": "增值税普通发票"}

   至少准备 50 条高质量样本。

2. 安装与运行：

   pip install "unsloth[colab-new] @ git+https://github.com/unslothai/unsloth.git" pip install accelerate bitsandbytes

   创建finetune.py：

   from unsloth import is_bfloat16_supported from unsloth import UnslothTrainer, UnslothModel from trl import SFTTrainer from transformers import TrainingArguments import torch model, tokenizer = UnslothModel.from_pretrained( model_name = "unsloth/Qwen2-1.5B-Instruct-bnb-4bit", max_seq_length = 2048, dtype = None, # 自动选择 bfloat16 或 float16 load_in_4bit = True, ) # 加载数据集（支持 jsonl） from datasets import load_dataset dataset = load_dataset("json", data_files = "data.jsonl", split = "train") trainer = UnslothTrainer( model = model, tokenizer = tokenizer, train_dataset = dataset, dataset_text_field = "text", max_seq_length = 2048, packing = True, args = TrainingArguments( per_device_train_batch_size = 2, gradient_accumulation_steps = 4, warmup_steps = 5, max_steps = 60, learning_rate = 2e-4, fp16 = not is_bfloat16_supported(), bf16 = is_bfloat16_supported(), logging_steps = 1, output_dir = "outputs", optim = "adamw_8bit", weight_decay = 0.01, ), ) trainer.train() model.save_pretrained("my_qwen2_finetuned")

   在 M2 Ultra（64GB）上，60 步训练耗时 18 分钟；在 M1 Pro（16GB）上，耗时 32 分钟。训练完成后，my_qwen2_finetuned文件夹即为你的专属模型，可用 Ollama 直接加载：ollama create mymodel -f Modelfile（Modelfile 中指定FROM ./my_qwen2_finetuned）。

实操心得：微调不是“越多越好”。我测试过：对发票类型标准化任务，50 条样本 + 60 步训练，准确率从基座模型的 72% 提升至 98.3%；增加到 200 条样本，准确率仅提升至 98.7%，但训练时间翻倍。关键在于样本质量——每条样本必须覆盖真实业务中的歧义点（如“专票”、“增专”、“增值税专票”都应映射到同一标准术语）。

4. 核心技术点深度解析：为什么这些方案能稳定落地？

4.1 GGUF 量化格式：本地运行的基石

所有能在消费级硬件上流畅运行的 LLM，其背后都依赖 GGUF 这一由 llama.cpp 团队定义的量化模型格式。它不是简单的“压缩”，而是一套完整的、面向推理优化的存储与计算协议。

GGUF 的核心设计哲学是：将模型权重、元数据、量化参数全部打包进单一文件，并支持按需加载（lazy loading）。传统 PyTorch.bin文件需将整个模型加载到内存，而 GGUF 文件可只加载当前推理所需的层（例如，当处理短文本时，只加载前几层的注意力权重）。这直接解决了内存瓶颈。

量化级别选择直接影响性能与精度平衡：

我实测 Q4_K_M 在 Qwen2-1.5B 上，对中文法律文本的理解准确率仅比 Q8_0 低 1.3%，但内存节省 50%，速度提升 3.4 倍。这意味着，你完全可以用一台 16GB 内存的笔记本，同时运行两个不同用途的 Q4_K_M 模型（如一个处理合同，一个处理邮件），互不干扰。

注意：量化不是“越低越好”。Q2_K 以下的量化会导致模型崩溃（loss explosion），Q3_K_L 是目前稳定性的下限。llama.cpp 的quantize工具默认推荐 Q4_K_M，这是经过数千次测试验证的甜点区间。

4.2 RAG 架构中的“检索-重排序-生成”三级流水线

一个健壮的 RAG 系统，绝非简单“向量检索 + prompt 拼接”。它必须包含三个不可省略的环节：

1. 粗检（Retrieval）：用嵌入模型（如nomic-embed-text）将 query 向量化，在向量库中进行近邻搜索（ANN），召回 top-k（通常 k=5）个最相关 chunk。这步快但粗糙，可能召回语义相近但事实错误的片段。
2. 精排（Re-ranking）：对粗检结果，用交叉编码器（Cross-Encoder）进行二次打分。例如BAAI/bge-reranker-base，它将 query 与每个 chunk 拼接后输入 BERT，输出更精确的相关性分数。这步慢但准，能过滤掉“看似相关实则无关”的噪声。
3. 生成（Generation）：将精排后的 top-3 chunk 与原始 query 拼接为 prompt，送入 LLM 生成最终答案。关键技巧是：在 prompt 中明确指令“仅根据提供的参考资料作答，若资料未提及，请回答‘未找到相关信息’”，并强制模型在答案末尾标注引用编号（如[1][3]）。

我在为某金融机构搭建财报分析助手时，发现跳过精排环节，模型会将“净利润同比增长 12%”错误关联到“营收同比下降 5%”的 chunk，生成矛盾结论；加入bge-reranker-base后，错误率从 23% 降至 1.8%。精排模型本身很小（< 50MB），推理一次仅需 300ms，却能大幅提升最终答案可信度。

4.3 提示工程的“三明治结构”：可控输出的黄金公式

面对通用大模型，提示词不是“多写点描述”，而是遵循严格结构。我总结出最有效的“三明治结构”：

[角色定义] + [任务指令] + [约束条件] + [输入数据] + [输出格式]

以生成客服回复为例：

你是一名资深电商客服主管，拥有 8 年处理跨境退货纠纷的经验。请根据以下买家投诉内容，生成一条专业、克制、包含解决方案的回复。要求：1. 开头致歉，2. 明确说明处理方案（退款/补发/优惠券），3. 不承诺无法兑现的事项，4. 全文不超过 120 字。 【投诉内容】 订单 #20240511-8892，收到商品有严重划痕，要求全额退款并赔偿精神损失费。 【回复】 尊敬的顾客，非常抱歉给您带来不便！经核实，我们将为您办理全额退款，并额外赠送一张 50 元无门槛优惠券作为补偿。退款将在 24 小时内原路返回。感谢您的理解与支持！

这个结构的关键在于：角色定义赋予模型“人格锚点”，任务指令明确动作，约束条件划定安全边界，输入数据提供上下文，输出格式强制结构化。我测试过，使用此结构后，模型回复的合规率（符合公司 SOP）从 64% 提升至 92%，且人工修改率下降 70%。

4.4 LoRA 微调的原理与参数选择逻辑

LoRA（Low-Rank Adaptation）之所以能在消费级硬件上微调 7B 模型，是因为它不更新原始权重，而是在 Transformer 的注意力层中，插入一对低秩矩阵（A 和 B），使得W' = W + α * A * B。其中 W 是原始权重，A 和 B 是可训练的小矩阵（例如 768×8 和 8×768），α 是缩放因子。

参数选择直接决定效果：

• rank（r）：决定 A/B 矩阵的中间维度。r=8 是通用起点；r=16 适合复杂任务（如法律条款生成）；r=4 适合简单分类。增大 r 提升能力但增加显存，r=16 时显存占用比 r=8 高 40%。
• lora_alpha（α）：控制 LoRA 更新的强度。通常设为 r 的 2 倍（如 r=8，则 α=16），保证α/r = 2的比例能平衡更新幅度。
• lora_dropout：防止过拟合，设为 0.1 即可，无需调优。

Unsloth 默认配置r=64, alpha=128是为 A100 设计的，对 M1/M2 应改为r=16, alpha=32。我实测在发票类型标准化任务上，r=16的准确率（98.3%）与r=64（98.5%）几乎无差别，但训练显存从 14GB 降至 6.2GB，使 16GB 内存设备成为可能。

5. 常见问题与排查技巧实录：那些没人告诉你的坑

5.1 问题速查表：高频故障与秒级修复

5.2 独家避坑技巧：来自 127 次失败实验的总结

技巧一：PDF 解析的“三重校验法”
不要相信任何单一解析工具。我处理过 300+ 份企业 PDF，发现：

• PyMuPDF（fitz）擅长解析文字版 PDF，但对表格识别差；
• pdfplumber表格识别强，但对复杂排版易乱序；
• unstructured综合能力强，但需联网调用 API。
  我的方案：先用PyMuPDF提取文本，若检测到表格（page.find_tables()返回非空），则切换pdfplumber专门提取表格，最后用正则清洗合并。代码封装为robust_pdf_loader.py，已开源在 GitHub。

技巧二：RAG 中的“chunk size 黄金比例”
chunk 太小（< 128 token）：丢失上下文，如“甲方应在付款后 30 日内交付”被切为两段，模型无法关联；
chunk 太大（> 512 token）：向量表示模糊，检索精度下降。
实测结论：对中文法律/商业文档，chunk_size=256+chunk_overlap=64是最优解。用 LlamaIndex 的SentenceSplitter，设置chunk_size=256, chunk_overlap=64，配合paragraph_separator="\n\n"，能完美保留段落语义。

技巧三：微调数据的“负样本注入法”
只给模型看“正确答案”，它会过度自信。我在发票类型任务中，特意加入 10% 的负样本：

{"instruction":"判断发票类型","input":"需要开票","output":"未明确类型，请确认是专票还是普票"}

这迫使模型学会“不确定时主动询问”，上线后客服转人工率下降 35%。负样本不是噪音，而是教模型认识自己的边界。

技巧四：本地模型的“温度值陷阱”
很多人以为temperature=0最稳定，实则不然。Qwen2 等新模型在temperature=0.3时，既保持逻辑连贯，又避免机械重复；temperature=0反而容易陷入“循环 token”（如无限输出“好的好的好的…”）。我的默认配置是：推理用temperature=0.3, top_p=0.9，微调用temperature=0.7（鼓励探索）。

5.3 性能监控：如何判断你的 LLM 应用是否“健康”

一个可交付的 LLM 应用，必须监控三项核心指标：

1. 首 token 延迟（TTFT）：从发送请求到收到第一个字符的时间。健康值：< 1.5 秒（本地）/< 800ms（云 API）。超时说明模型加载或量化配置不当。
2. token 生成速率（TPS）：每秒生成 token 数。健康值：Q4_K_M 7B 模型在 M1 Pro 上应 ≥ 35 tps。若 < 20，检查是否启用了numa绑核或mlock内存锁定。
3. 事实准确率（F1）：对 100 条测试 query，人工标注标准答案，计算模型输出的 F1 值。健康值：RAG 应用 ≥ 85%，微调模型 ≥ 95%。低于此值，优先检查数据质量而非模型参数。

我用一个简单的monitor.py脚本，每 5 分钟自动采样 10 条 query，记录上述指标并写入 CSV。当 TPS 连续 3 次 < 25，自动触发告警并重启 Ollama 服务。这套监控，让我在过去半年中，0 次因模型性能问题导致业务中断。

6. 从“能用”到“好用”：构建可持续演进的 LLM 能力体系

6.1 个人能力演进路线图：三个月达成自主开发闭环

我把 LLM 开发能力拆解为四个递进层级，每个层级对应明确的交付物和时间节点：

• 第 1 周：工具链掌控者
  目标：独立完成模型下载、本地推理、基础提示词编写。
  交付物：一个 VS Code 插件 + 10 条高频业务提示词模板（如“总结会议纪要”、“生成周报要点”）。
• 第 2 周：RAG 实践者
  目标：为任意 PDF/Notion 页面构建可查询的知识库。
  交付物：一个rag_setup.sh脚本，输入 URL 或文件路径，自动生成 API 服务。
• **第 3 周