企业官网建设流程全解析

如果最近你也在关注生成式 AI 的落地，大概率会注意到一个趋势：越来越多的人开始把大模型装进自己的电脑，而不是把所有请求都交给云端 API。原因其实很现实——当你要处理公司内部文档、私人笔记、或者是不能随意出网的项目资料时，数据到底放在哪里，本身就是一道选择题。本文把我从零搭建本地 AI 助手的完整过程整理成一份可复现的教程，内容分为两个实战阶段：第一阶段基于 Ollama 在本地跑通纯对话服务，第二阶段为模型接入自己的文档知识库，实现 RAG 问答。整个教程不要求你有昂贵的服务器，也不要求精通深度学习，主要用到的开发语言是 Python，中间会穿插大量可以直接复制的代码和命令。

1. 本地 AI 是什么，为什么值得折腾

1.1 本地 AI 的概念

本地 AI，简单说就是让大语言模型（LLM）在我们自己的电脑或内网服务器上运行，而不是通过调用远程 API 来使用。要做到这一点，通常需要三样东西：一是开源模型的权重文件，二是负责加载和推理的引擎，三是一个调用层或者交互界面。常见的开源模型包括 Qwen、Llama、Mistral、DeepSeek 系列等，它们都有不同参数规模的版本，小到 1B、3B，大到 70B、上百 B，参数越大对硬件要求越高。

很多人会把“本地 AI”和“私有化部署”混在一起，其实它们不完全等价。私有化部署强调的是部署环境的隔离和可控，本地 AI 更强调“模型跑在本机、离线也能用”的体验。你可以把本地 AI 理解成自己电脑上的一个专属助手，它没有外部流量成本，也不受网络波动影响，真正做到了模型权重和应用代码都在自己手里。它的能力上限很大程度上取决于你的硬件配置，但有一点很明确：随着开源模型能力的快速提升，本地运行一个够用的助手已经不是遥不可及的事情了。

1.2 本地 AI 与云端 API 的差异

在动手之前，最好先弄清楚本地 AI 和云端 API 各自的优缺点，这样你才知道自己的场景该选哪条路。

从这张表能看出来，本地 AI 最大的优势是隐私、离线和可控成本；而云端 API 最大的优势则是开箱即用、模型上限高。对于个人学习、企业内部知识库问答、代码辅助这类场景，本地 AI 的性价比往往更高。

1.3 适合本地 AI 的场景

本地 AI 最适合的场景大概有四类。

第一类是隐私敏感型任务，例如把企业内部规章制度、项目文档、财务说明做成问答机器人，或者用模型帮助你整理没有公开的调研资料。这类数据不适合发往外部接口。第二类是离线或弱网环境，比如在出差途中、内网隔离环境、甚至没有公网连接的实验室里，你依然需要一个可用的智能助手。第三类是高频且成本敏感的小任务，比如日志摘要、邮件草稿、代码注释生成，这类任务调用云端 API 的积少成多也是不小的开销，本地跑会更省。第四类是学习和实验，如果你想研究大模型的推理机制、微调流程、量化压缩，或者在开发 AI 应用时反复调试 Prompt，本地方案可以让你随心所欲地操作而不产生额外费用。

当然，本地 AI 也有不擅长的地方：比如你需要一个超大规模模型来回答深度推理问题，或者需要极强的多模态生成能力，又或者你完全不想折腾硬件，这时候云端 API 依然是更好的选择。务实一点的做法是“本地跑基础任务 + 云端做高难任务”，两者互补，而不是非要选一边。

2. 环境准备：硬件、系统与工具选型

2.1 硬件要求与模型规模参考

很多新手最关心的问题是：“我的电脑到底能不能跑？”先给出一个经验性的参考，具体数据会因模型量化方式和推理引擎不同而有差异。

这里要区分两个概念：一个是显存（VRAM），一个是内存（RAM）。模型推理时，权重数据优先放进显存，显存不够时会卸载到内存，速度会明显下降。如果只有 CPU，那么内存大小直接决定你能加载多大模型。另一个容易被忽略的是“上下文长度”，长上下文会占用额外显存，同样一个模型，你开 8K 上下文和开 32K 上下文，对硬件的压力完全不同。

本文后面的示例以 7B 级别模型为主，哪怕你手头只有一台 16GB 内存的普通笔记本，也能完整跑通全部代码。

2.2 软件清单

接下来搭建本地方案，推荐的软件组合非常简单：

• 推理引擎：Ollama，负责模型管理、加载和提供 HTTP API。
• 运行环境：Python 3.9+，用于写调用代码。
• HTTP 客户端：requests，用来调用 Ollama API，也可以用官方 Python 库。
• 可选工具：向量数据库（Chroma、FAISS 等），本文先用手写检索演示原理。
• 系统平台：Windows、macOS、Linux 均可，关键是安装对应的 Ollama 版本。

版本说明写在这里：技术工具更新比较频繁，本文示例以当前主流版本为参考，如果你看到的版本有差异，不要焦虑，重点参考配置思路和代码结构。遇到接口不兼容时，以官方文档为准。

2.3 安装与验证 Ollama

Ollama 的安装方式很直接。macOS 和 Windows 用户直接访问官网下载对应安装包，安装完成后 Ollama 会作为后台服务自动运行，系统托盘或菜单栏会出现图标。Linux 用户可以在终端执行官方提供的安装脚本：

curl -fsSL https://ollama.com/install.sh | sh

安装完成后，打开终端验证：

ollama --version

如果能正常打印版本号，说明安装成功。接下来确认服务是否在运行：

ollama serve

正常情况下，这个命令会启动 Ollama 服务并监听127.0.0.1:11434。如果你安装的是桌面版，通常服务已经自动启动了，不需要手动执行。再确认一下当前本地已有的模型：

ollama list

如果刚安装，这个列表是空的，说明还没有拉取任何模型。

2.4 拉取并运行第一个模型

选择一个适合入门的中文模型，例如通义千问 Qwen2.5 系列的 7B 版本：

ollama pull qwen2.5:7b

拉取过程中会显示进度条，模型文件比较大，7B 量级模型大约 4.7GB 左右，具体大小取决于量化格式。耐心等待完成。拉取成功后，直接运行：

ollama run qwen2.5:7b

你会进入一个交互式对话界面，输入你好试试：

>>> 你好 你好！我是你的智能助手，有什么可以帮你的吗？

能出现这样的回复，说明你的本地模型已经成功跑起来了。此时按/bye或Ctrl + D退出对话。

3. 核心概念：模型、推理引擎与 RAG

3.1 模型参数、量化与上下文长度

模型名称里的 7B、14B 表示参数量，7B 就是 70 亿参数。参数越多，模型记忆的知识和推理能力通常越强，但同时需要更大的显存和更长的推理时间。对于大多数个人使用场景，7B 是一个性价比很高的起点。

量化是另一个重要概念，它把模型权重的精度降低，比如从 16 位浮点数压缩到 4 位整数，以减小文件体积和内存占用。Ollama 默认会给模型做量化处理，常见标签后缀如q4_K_M、q8_0就代表不同的量化级别。通常 Q4 是性能和质量的均衡点，Q8 质量更高但体积更大，Q2、Q3 体积更小但输出质量会明显下降。

上下文长度指的是一次会话中模型能“看到”的文本总量。对话时你的历史消息、知识库检索出的片段，都会进入上下文。上下文越长，硬件开销越大。如果发现模型回答变慢或者直接报显存不足，可以先考虑把上下文长度调小，比如从 8K 调到 4K。

3.2 Ollama 做了什么

Ollama 的本质是一个模型管理与推理服务工具。它负责从模型仓库拉取模型、管理本地模型文件、加载模型到内存/显存、通过底层推理引擎执行生成，然后对外提供 HTTP API。这意味着你的业务代码不需要关心模型加载细节，只需要向http://localhost:11434发送请求即可。

Ollama 的价值在于把“本地跑大模型”从一件折腾事变成了一个标准化操作。你不需要手动配置 llama.cpp，不需要编译推理框架，也不用纠结依赖冲突。它会为不同硬件选择合适的计算后端，在支持 CUDA 的环境下自动利用 GPU。

用一句不严谨但好理解的话来说：Ollama 之于大模型，有点像 Docker 之于应用——它提供了一致的运行环境、统一的命令和 API，让你专注于模型本身，而不是底层实现。

3.3 RAG 链路拆解

RAG（Retrieval-Augmented Generation，检索增强生成）是本地 AI 最实用的能力之一，它让模型能够基于你自己的文档回答问题。因为模型训练完成后，知识是固定的，你不可能让它凭空知道你的内部表格或产品手册。这时候 RAG 的思路是：先在你的文档库里检索相关片段，再把片段拼进 Prompt，最后让模型基于这些内容生成回答。整体流程可以用下面这张 ASCII 图表达：

文档加载 -> 文本切分 -> 向量化(Embedding) -> 存入向量库 用户提问 -> 向量化(Embedding) -> 相似度检索 -> 取 Top-K 片段 拼接 Prompt -> 调用大模型 -> 生成回答

拆开看，RAG 包含五个关键步骤：

1. 文档加载，读取 PDF、TXT、Markdown 等格式的原始文本。
2. 文本切分，把长文档切成适合模型处理的块，避免一次性塞入过多内容。
3. 向量化，用 Embedding 模型把文本块转换成向量。
4. 相似度检索，计算用户问题向量与文档向量之间的距离，取最相关的几个块。
5. 生成回答，把检索结果和原始问题拼进 Prompt 交给大模型。

RAG 的最大价值在于“用检索代替训练”，不用微调模型就能让模型掌握你私有知识库的内容，成本低、更新快。

3.4 Embedding 与向量检索原理

Embedding 模型的工作是把一段文本映射成一个固定长度的数值向量，例如nomic-embed-text模型输出的向量维度通常是 768。向量之间可以通过余弦相似度衡量语义相似程度，语义相近的文本，向量方向就越接近，余弦值越大。

为什么不能用关键词匹配来做检索？因为用户可能用不同的表达问同一件事。比如文档里写的是“账单导入支持 CSV”，用户问的是“我导 Excel 行不行”，关键词匹配就不一定能命中，但语义向量可以捕捉到两者的关联。当然，向量检索也不是万能的，它依然需要配合好的切分策略和合适的检索阈值。

理解这个原理之后，你就能明白为什么本地 AI 的体验差异往往不在模型本身，而在工程细节：切分是否合理、向量模型是否合适、检索召回是否准确，这些都会直接影响最终回答质量。

4. 第一阶段实战：跑通纯对话服务

4.1 了解 Ollama 的 HTTP API

Ollama 启动后，会在本地开放一个 HTTP 服务。对话交互可以用官方客户端，但我们在做工程集成时，更关心的是 API 接口。两个最常用的接口是：

• POST /api/generate，传入 prompt 生成文本，适合简单对话和补全。
• POST /api/chat，传入消息列表，适合多轮对话。

另外还有一个POST /api/embed接口，用于获取文本向量，后面的 RAG 实战会用到。下面先用最简单的方式测试 generate 接口。打开终端执行：

curl http://localhost:11434/api/generate -d '{ "model": "qwen2.5:7b", "prompt": "请用一句话介绍你自己", "stream": false }'

返回结果是一个 JSON，里面包含response字段，那就是模型生成的文本。stream: false表示关闭流式输出，等全部生成完成再返回；如果stream: true，则一行一行返回结果，适合做打字机效果。

4.2 使用 Python 调用非流式接口

先用 Python 写一个最简单的调用示例。新建目录local-ai-demo，在里面创建文件basic_call.py：

# 文件路径：local-ai-demo/basic_call.py import requests OLLAMA_URL = "http://localhost:11434/api/generate" MODEL_NAME = "qwen2.5:7b" def ask(prompt: str) -> str: payload = { "model": MODEL_NAME, "prompt": prompt, "stream": False, "options": { "temperature": 0.7, "num_predict": 512 } } resp = requests.post(OLLAMA_URL, json=payload, timeout=180) resp.raise_for_status() data = resp.json() return data.get("response", "") if __name__ == "__main__": result = ask("用三句话介绍 RAG 的原理") print(result)

运行：

python basic_call.py

这里有三个值得注意的细节。第一，options.temperature控制随机性，数值越大回答越多变，数值越小回答越确定，知识问答类任务建议调到0到0.3之间。第二，num_predict限制生成的最大 Token 数，避免回答过长导致等待时间太久。第三，timeout要设置得宽一点，因为本地推理速度受硬件影响较大，7B 模型在 CPU 上生成几百字可能需要几十秒甚至更久。

4.3 实现流式命令行对话助手

非流式接口适合批量场景，但交互体验不够好。真正的对话助手应该像 ChatGPT 一样逐字输出。下面用流式接口实现一个命令行版本。创建文件chat_cli.py：

# 文件路径：local-ai-demo/chat_cli.py import json import requests OLLAMA_URL = "http://localhost:11434/api/generate" MODEL_NAME = "qwen2.5:7b" SYSTEM_PROMPT = "你是一个友好、专业的中文助手。" def chat_stream(prompt: str, history: list): messages = history + [{"role": "user", "content": prompt}] prompt_text = build_prompt(messages) payload = { "model": MODEL_NAME, "prompt": prompt_text, "stream": True, "options": {"temperature": 0.7} } resp = requests.post(OLLAMA_URL, json=payload, stream=True, timeout=300) resp.raise_for_status() for line in resp.iter_lines(): if not line: continue data = json.loads(line.decode("utf-8")) piece = data.get("response", "") if piece: yield piece if data.get("done", False): break def build_prompt(messages): rendered = [f"System: {SYSTEM_PROMPT}\n"] for msg in messages: role = "User" if msg["role"] == "user" else "Assistant" rendered.append(f"{role}: {msg['content']}\n") rendered.append("Assistant:") return "\n".join(rendered) if __name__ == "__main__": history = [] print("本地 AI 命令行助手，输入 exit 退出\n") while True: user_input = input("你：") if user_input.strip().lower() in ("exit", "quit"): break print("AI：", end="", flush=True) answer_parts = [] for piece in chat_stream(user_input, history): print(piece, end="", flush=True) answer_parts.append(piece) print("\n") history.append({"role": "user", "content": user_input}) history.append({"role": "assistant", "content": "".join(answer_parts)})

运行：

python chat_cli.py

这样你就得到了一个能多轮对话的本地助手。注意这里的 Prompt 拼接方式比较朴素，没有用 ChatML 模板，但对于简单对话已经足够。如果你需要更标准的消息格式，可以使用/api/chat接口，它直接接受messages列表，内部会自动处理好模板。

4.4 运行结果与体验优化

运行上面代码后，你会看到类似下面的交互效果：

你：你好 AI：你好！有什么我可以帮你的吗？ 你：RAG 和微调有什么区别？ AI：RAG 通过检索外部知识来增强生成，不需要改变模型参数；微调则是用数据继续训练模型，让模型本身学会新能力……

到这里，第一阶段就成功了。你已经拥有了一个完全跑在本地的 AI 对话服务。这个阶段的关键收获是理解 Ollama API 的基本调用方式：如何传参、如何处理流式输出、如何管理多轮历史。后面做知识库问答时，我们会复用这套调用逻辑。

5. 第二阶段实战：给模型接上知识库

5.1 准备示例文档

为了让例子完整可运行，我们伪造一个简单的产品文档作为知识库。假设你有一个虚构产品叫“小智记账”，把它的使用说明保存为docs/product.txt：

小智记账是一款本地优先的记账应用，支持账单导入和自动分类。 账单导入支持 CSV、Excel、支付宝导出文件、微信导出文件。 导入步骤：打开应用，进入设置，选择导入账单，上传文件后等待解析完成。 自动分类功能依赖本地规则引擎，不会上传用户数据。 常见问题：导入失败时，请检查文件编码是否为 UTF-8，并确认列名包含日期、金额、类别。 如果匹配不到分类，请在分类设置页面手动建立关键词与分类的映射关系。

这个文档足够小，方便观察切分和检索效果。实际项目中你可以替换成自己的产品手册、公司制度或技术文档，原理完全一样。

5.2 文档切分与向量化流程

创建build_kb.py，它负责读取文档、切分文本、生成向量并保存成索引文件。代码如下：

# 文件路径：local-ai-demo/build_kb.py import re import pickle import requests EMBED_MODEL = "nomic-embed-text" EMBED_URL = "http://localhost:11434/api/embed" DOC_DIR = "./docs" KB_FILE = "./kb.pkl" def load_texts(doc_dir): texts = [] import os for fname in os.listdir(doc_dir): path = os.path.join(doc_dir, fname) if fname.endswith((".txt", ".md")): with open(path, "r", encoding="utf-8") as f: texts.append(f.read()) return texts def split_text(text, chunk_size=200, overlap=50): # 先按句末标点粗切，避免把完整句子切开 segments = re.split(r"(?<=[。！？.!?])", text) segments = [s.strip() for s in segments if s.strip()] chunks = [] current = "" for seg in segments: if len(current) + len(seg) <= chunk_size: current += seg else: if current: chunks.append(current) overlap_text = current[-overlap:] if overlap else "" current = overlap_text + seg if current: chunks.append(current) return chunks def get_embeddings(texts): resp = requests.post(EMBED_URL, json={"model": EMBED_MODEL, "input": texts}, timeout=120) resp.raise_for_status() return resp.json()["embeddings"] def main(): docs = load_texts(DOC_DIR) all_chunks = [] for doc in docs: all_chunks.extend(split_text(doc)) if not all_chunks: print("没有读取到任何文档") return vectors = get_embeddings(all_chunks) with open(KB_FILE, "wb") as f: pickle.dump({"chunks": all_chunks, "vectors": vectors}, f) print(f"构建完成，共 {len(all_chunks)} 个文本块，向量维度 {len(vectors[0])}") if __name__ == "__main__": main()

首先运行一次ollama pull nomic-embed-text拉取向量模型，然后执行：

python build_kb.py

这段代码里有三个关键点需要解释。第一个是切分方式，按句号先切、再拼接，这样能减少“一句话被拦腰截断”的情况。第二个是chunk_size和overlap，前者控制每块的大小，后者让相邻块之间有重叠，避免检索时找不到跨边界的答案。第三个是overlap_text = current[-overlap:]，意思是把上一块的结尾拼到下一块开头，保证上下文连续。

5.3 相似度检索与 RAG 问答

索引构建完成后，接下来是查询和回答环节。创建rag_chat.py：

# 文件路径：local-ai-demo/rag_chat.py import pickle import requests EMBED_MODEL = "nomic-embed-text" EMBED_URL = "http://localhost:11434/api/embed" GENERATE_URL = "http://localhost:11434/api/generate" KB_FILE = "./kb.pkl" MODEL_NAME = "qwen2.5:7b" TOP_K = 3 def get_embedding(text): resp = requests.post(EMBED_URL, json={"model": EMBED_MODEL, "input": text}, timeout=60) resp.raise_for_status() return resp.json()["embeddings"][0] def cosine_similarity(a, b): dot = sum(x * y for x, y in zip(a, b)) norm_a = sum(x * x for x in a) ** 0.5 norm_b = sum(x * x for x in b) ** 0.5 if norm_a == 0 or norm_b == 0: return 0 return dot / (norm_a * norm_b) def search(chunks, vectors, query_vector, top_k=TOP_K): scored = [] for i, vec in enumerate(vectors): score = cosine_similarity(query_vector, vec) scored.append((score, i)) scored.sort(reverse=True) return [chunks[i] for score, i in scored[:top_k]], scored[:top_k] def build_prompt(question, contexts): context_block = "\n\n".join(contexts) return f"""你是知识库问答助手。请严格根据以下资料回答问题。如果资料中找不到答案，请回答“资料中没有提到”，不要编造。 资料： {context_block} 问题：{question} 回答：""" def generate_answer(prompt): payload = { "model": MODEL_NAME, "prompt": prompt, "stream": False, "options": {"temperature": 0.2, "num_predict": 400} } resp = requests.post(GENERATE_URL, json=payload, timeout=180) resp.raise_for_status() return resp.json().get("response", "") if __name__ == "__main__": with open(KB_FILE, "rb") as f: kb = pickle.load(f) chunks = kb["chunks"] vectors = kb["vectors"] print("知识库问答助手，输入 exit 退出\n") while True: question = input("问题：") if question.strip().lower() in ("exit", "quit"): break q_vec = get_embedding(question) hit_chunks, hit_score = search(chunks, vectors, q_vec) print("\n--- 检索到的资料片段 ---") for i, (score, idx) in enumerate(hit_score): print(f"[{i+1}] 相似度 {score:.4f}：{chunks[idx]}") print("------------------------\n") prompt = build_prompt(question, hit_chunks) answer = generate_answer(prompt) print(f"回答：{answer}\n")

5.4 运行验证与预期输出

启动前确认已经执行过python build_kb.py，然后运行：

python rag_chat.py

提问一个文档中明确包含答案的问题：

问题：小智记账支持哪些格式的账单导入？

预期看到类似输出：

--- 检索到的资料片段 --- [1] 相似度 0.87xx：小智记账是一款本地优先的记账应用，支持账单导入和自动分类。账单导入支持 CSV、Excel、支付宝导出文件、微信导出文件。 --- 回答：根据资料，小智记账支持 CSV、Excel、支付宝导出文件、微信导出文件四种格式。

再提问一个文档没有覆盖的问题：

问题：小智记账支持云同步吗？

如果检索到的片段和问题相关性不够，回答应该是“资料中没有提到”。这正是 RAG 与普通对话的差别：它不会“自由发挥”文档里不存在的内容，更符合知识库工具的安全要求。

5.5 为什么检索质量比模型大小更影响体验

很多人刚开始做 RAG，第一反应是“我要换更大的模型”，但实测下来会发现，真正决定问答质量的往往是检索环节。如果文档切分不合理、Embedding 模型不匹配、Top-K 设置过大或过小，再强的模型也无法从错误的信息中得出正确答案。

举个常见例子：你的文档有 100 页，用户问了一个只有第 85 页才出现的问题。如果切分时把 85 页的内容和上下文关在一起，或者向量检索召回时没有排到前三，回答就会偏离。相比之下，选择一个适合中文的 Embedding 模型、合理设置块大小和重叠度、再叠加一个相似度阈值，对效果的提升通常比盲目加大大模型参数更明显。这也是本文用一套纯手写代码演示 RAG 的原因——先理解链路，再上工程框架，后面无论换 Chroma 还是 FAISS，你都能快速适应。

6. 常见问题与排查思路

本地 AI 部署最大的障碍不是代码本身，而是环境、资源和模型兼容性问题。这里整理了高频问题，按排查顺序给出解决思路。

拉取模型失败是最常见的问题。优先检查网络是否能正常访问模型仓库；如果公司网络有限制，可以考虑在允许的环境下拉取模型，再把模型目录拷贝到目标机器。需要注意，这种做法需要确认模型文件完整，更稳妥的方式是使用ollama pull重新校验。

显存不足的问题也经常出现。很多人第一次跑 14B 模型，结果 8GB 显存直接被挤爆。这时候不要硬扛，有两个立竿见影的方法：一是换成同系列的 7B 版本，二是通过OLLAMA_MAX_LOADED_MODELS等环境变量控制加载行为。如果显存不够但内存充足，系统会退化成 CPU 推理，虽然能跑但速度会明显下降。

检索不准的问题排查看似复杂，实际上就是几个变量在互相作用。先把 chunk_size 调小一点，比如从 200 调到 100，看看是否命中；再把 overlap 调大一点；如果还不行，检查 Embedding 模型是否适合中文；最后再调整 Top-K 数量。按这个顺序排查，大多数问题都能解决。

7. 工程化最佳实践与性能调优

7.1 模型与量化选择

生产环境选择模型时，不要只看参数大小，还要看具体任务。中文对话和知识库问答，Qwen 系列和 DeepSeek 系列都比较稳；代码生成场景可以关注 Qwen-Coder 或 DeepSeek-Coder；英文场景则可以考虑 Llama、Mistral。如果显存紧张，优先选择量化级别合适的小模型，而不是硬上一个超出资源的模型导致频繁 OOM。

量化的选择也有规律：Q4_K_M 是通用推荐，体积和质量的平衡最好；追求更高输出质量且硬件充足时用 Q8；显存非常紧张时再用 Q3，但要接受明显的质量下降。建议准备一个“测试问题集”，选模型时用同样的问题集在几个候选模型上跑一遍，比只看参数更可靠。

7.2 文本切分与检索调优

文本切分不是越短越好，也不是越长越好。块太短会丢失上下文，块太长又会混入无关内容。一个比较实用的经验是：普通文档按 200 到 500 个字符切块，重叠 20 到 50 个字符；如果文档有明确的结构层级，可以在切分前先按标题分段，再对每个小节切分。

检索调优方面，增加一个“最低相似度阈值”是很有必要的。当用户的问题和知识库内容完全不相关时，与其硬拼一个答案，不如直接告诉用户“资料中没有提到”。这个阈值需要根据自己的文档特点调试，一般从 0.5 开始观察，太低会漏答，太高会拒答。Top-K 建议从 3 开始，需要更完整的答案时可以增加到 5，但片段太多也会稀释大模型的注意力。

7.3 接口封装与用户体验

把对话代码直接写在业务脚本里只适合学习。工程化时，建议先做一层 API 封装：把 Ollama 调用封装成独立的服务模块，对外提供标准接口，不暴露模型名和底层的 Prompt 拼接细节。即使未来更换推理引擎，业务侧也不用大改。

流式输出是提升体验的关键。同样是生成 500 字，非流式接口会让用户干等几十秒，流式接口则能在一两秒内就开始输出内容。如果开发 Web 应用，可以用 SSE（Server-Sent Events）或 WebSocket 把流式结果推给前端。另外，历史消息管理也要注意，多轮对话时不能无限堆叠历史，否则上下文超长后成本和延迟都会上升，建议用一个滑动窗口保留最近几轮。

7.4 安全与数据合规

本地 AI 最大的卖点是隐私，但“本地”不代表绝对安全。Ollama 服务默认监听在127.0.0.1，尽量不要改成0.0.0.0暴露到局域网或公网，除非你做好了严格的访问控制。如果团队成员需要共享这个服务，建议在前面加一层带身份认证的反向代理。

知识库内容要考虑权限边界。一个常见问题是：所有用户都能检索全部文档，导致越权访问。正确的做法是在检索层就加入权限过滤，根据用户角色或部门限制可见文档范围，而不是等模型生成回答后再拦截。日志同样需要脱敏，避免把用户的提问内容原样写入公共日志。

7.5 性能优化方向

性能优化从大到小排列，优先级最高的是硬件利用。先确认 GPU 是否真的被用上了，运行ollama ps，查看模型在哪一层被加载，GPU列显示是多少。如果显示 CPU，说明环境没配置好，优先检查显卡驱动和 CUDA 环境。

然后是减少重复计算。可以把 Embedding 结果缓存起来，相同文档不必每次重新生成向量；回答结果也可以缓存，热门问题直接命中缓存，避免重复推理。还有num_predict这个参数，很多开发者在聊天场景下不限制长度，结果让模型一直输出到超时，实际问题只需要几十个字，把生成长度限制在合理范围，吞吐量会有明显改善。

7.6 版本管理与模型迭代

本地模型同样需要版本管理。建议把一个固定的“当前生效模型”写入配置文件，而不是硬编码在代码里。模型文件较大，升级前先备份旧模型，确认新模型效果后再切换。评测时准备一份包含正常问题、边界问题、敏感问题在内的测试集，每次换模型后统一跑一遍，避免“感觉变好了”这种主观判断。

如果对回答质量有更高要求，下一步可以做模型微调（Fine-tuning）。RAG 解决的是“外部知识”问题，微调解决的是“输出风格和指令遵循”问题。两者可以叠加：先用微调让模型更听话，再用 RAG 提供事实依据。

8. 总结与后续学习路线

到这里，你已经完成了一条从零开始的本地 AI 之旅：安装了 Ollama，拉取并运行了开源大模型；用 Python 调通了 Ollama 的 HTTP API，实现了一个能流式输出的命令行对话助手；接着亲手搭建了一个简化版 RAG 系统，把自己准备的文档向量化，实现了基于本地知识的问答；最后排查了常见部署问题，并梳理了工程化落地时的关键实践。

下一步值得探索的方向有三个。第一个是向量数据库，把手工 pickle 存储替换为 Chroma 或 FAISS，体验真正的工业级检索；第二个是 Agent 能力，让模型学会调用工具、执行代码、访问外部接口，把本地 AI 从一个“问答机器”变成一个“执行助手”；第三个是微调和多模态，如果对模型质量和能力上限有更高要求，可以从 LoRA 微调和多模态模型入手。实践是理解大模型最好的方式，建议你先用自己的文档重新跑一遍完整流程，再动手改造代码，把项目逐步工程化。如果本文对你有帮助，欢迎收藏备用，也欢迎在评论区交流你踩到的坑。