"零成本"这三个字，放在智能客服项目的语境里，以前基本是句玩笑话。早些年做知识库问答，要么按 Token 付费调大模型 API，要么咬咬牙买卡做微调，再算上工程开发量，一个客服机器人没几万块下不来。但今年情况真的变了：本地推理框架发展很快，开源模型能力也够用，再加上向量数据库的部署门槛不断降低，一台普通电脑就能把"文档进、答案出"的完整知识库问答链路跑通。这篇文章就是把我用 Ollama + Milvus + DeepSeek 搭建一套 RAG 智能客服的完整过程做个复盘，从架构选型、环境部署、知识库处理，到检索生成的代码实现和排错经验，全部展开讲清楚。
我默认读者已经有 Python 基础，并且对 Docker 有最基本的了解。如果你刚开始接触 RAG，也不用担心，我会把每一步涉及的原理用大白话讲明白，保证你照着操作能复现，而不是看一堆飘着的概念。
1. 零成本RAG客服的架构逻辑与技术选型
1.1 为什么是 RAG，而不是微调模型
客服场景有一个典型特征：问题相对集中，答案高度依赖产品文档和业务规范。比如"如何退货""如何充值""某功能入口在哪里"，这些问题对应的答案就藏在现有文档里。解决这种问题有两种主流思路，一是微调大模型，让模型记住业务知识；二是做 RAG，每次提问时先从知识库检索相关内容，再把内容作为上下文交给模型生成回答。
微调在客服场景里其实没那么划算。一来业务文档更新频繁，每次更新都要重新准备训练数据、重新跑训练流程，维护成本高；二来模型微调会把知识"揉碎"到参数里，很难追溯它到底依据哪份文档回答，出了错也不容易定位。RAG 则完全不同，知识以文本片段的形式存在外部数据库里，更新知识库就是改文档重新入库，回答时还能返回来源，方便人工核查。
所以我的判断很明确：除非你的业务问答完全不依赖现有文档、需要模型凭空生成个性化回答，否则 RAG 是更快、更可控、更便宜的选择。
1.2 三个核心组件各自承担什么角色
技术选型定下来之后，要回答的问题是：每个环节用哪个工具。我的组合是 Ollama 负责本地跑模型，Milvus 负责向量存储与检索，DeepSeek 系列模型作为生成底座。它们的分工大概是这样的：
| 组件 | 职责 | 解决的核心问题 |
|---|---|---|
| Ollama | 本地模型运行框架，托管嵌入模型和生成模型 | 不用付费 API，不按次数计费，模型和数据都在本地 |
| Milvus | 向量数据库，存储文档片段的向量表示并执行相似度检索 | 在海量片段中快速找到与用户问题语义最接近的内容 |
| DeepSeek | 开源大模型，根据检索到的上下文生成最终客服回答 | 把原始材料组织成自然、准确、可读的回复 |
有人会问，嵌入模型是不是也算一个组件？对，嵌入模型我同样用 Ollama 跑，选择的模型是 BGE 系列。把嵌入也放到 Ollama 里，好处是整个模型管理统一在一个工具里，命令、接口风格一致，少搭一套环境。
1.3 RAG 完整数据链路回顾
在写代码之前，先把链路在大脑里过一遍。整个系统从数据侧和查询侧两条线展开：
数据侧：原始文档 → 解析成纯文本 → 切分成小块 → 嵌入模型向量化 → 写入 Milvus 集合。 查询侧：用户提问 → 问题向量化 → Milvus 相似度检索 → 返回 top-K 文本片段 → 与问题拼接成 Prompt → DeepSeek 生成回答 → 返回给用户。
这两条线看起来简单，每一环都有细节。尤其是分块大小、向量维度、检索阈值、提示词模板这几个点，直接决定最终问答效果的好坏。后面每一章我会把这几个关键点逐一拆开讲。
2. Ollama 部署与 DeepSeek 模型拉取：环境准备阶段的所有细节
2.1 Ollama 的安装方式和基础验证
Ollama 给我的第一印象是"省心"。它把模型下载、模型加载、Prompt 解析、显存/内存调度、API 暴露全都封装好了，你不需要关心背后的 llama.cpp 或者底层推理引擎是怎么工作的。Windows 和 macOS 用户直接下载安装包完成安装；Linux 用户可以通过官方脚本安装。装完之后，打开终端执行：
ollama list如果正常输出一个表格（初始可能是空表），就说明服务已经在运行了。Ollama 安装完成后默认会在后台启动一个本地服务，监听在 11434 端口，后续所有代码都是通过这个端口的 HTTP 接口和模型交互。
2.2 DeepSeek 模型怎么选：三档配置的取舍
在 Ollama 的模型库里，DeepSeek 系列有多个参数规模，我从资源占用和生成质量的平衡角度做了对比：
| 模型 | 参数量 | 最低配置参考 | 适用阶段 |
|---|---|---|---|
| deepseek-r1:1.5b | 15亿 | 4GB 内存 | 流程验证、Demo 演示 |
| deepseek-r1:7b | 70亿 | 8GB 内存起步 | 日常客服主力 |
| deepseek-r1:14b | 140亿 | 16GB 内存 / 6GB 显存 | 对回答质量要求更高的场景 |
我最终选择 7b 作为主力。原因有两个：一是通用办公机 16GB 内存能跑得动，在 CPU 推理下也有可接受的吞吐；二是客服问答本身是"基于给定材料组织回答"的任务，不需要模型具备特别强的百科知识和创造能力，7b 的指令跟随和文本组织能力已经足够。如果你有独立显卡，建议直接上 14b，显存能放下的话生成速度不是一个量级。
拉取模型执行：
ollama pull deepseek-r1:7b模型文件几个 GB 到十几个 GB 不等，下载耗时看网络情况。耐心等它完成，别中途切片重拉。拉取后可以用一条命令直接和模型对话验证：
ollama run deepseek-r1:7b "你好，请用一两句话做一个自我介绍"看到正常的中文回复，说明模型可以用了。
2.3 嵌入模型同样不能马虎：我选了 BGE 系列
很多第一次做 RAG 的人会把注意力全放在大模型上，忽视嵌入模型。实际上，整个系统检索质量的上限是由嵌入模型决定的。大模型负责把召回的文本组织成答案，但它无法凭空找回没被检索到的内容。如果嵌入模型对中文语义的判断不准，检索阶段就会召回一堆不相关片段，后面再怎么调 Prompt 都没用。
我选的是 bge-m3，这个模型在中文语义匹配任务上表现稳定，支持 8192 长度的文本输入，输出 1024 维向量，和 Milvus 配合很成熟。拉取命令同样简单：
ollama pull bge-m3需要特别说清楚的是，嵌入模型和生成模型的调用方式完全不同。生成模型走的是对话接口，传入 messages 列表返回文本；嵌入模型走的是嵌入接口，传入一段文本返回一个浮点向量数组。后面代码部分会展示具体调用方式。
2.4 Ollama API 的两种调用入口
Ollama 提供了两套 HTTP API。一套是原生接口，路径以/api/开头，比如/api/embed负责文本向量化，/api/chat负责对话生成。另一套是兼容接口，路径以/v1/开头，可以兼容 OpenAI 风格的 SDK。
http://localhost:11434/api/embed http://localhost:11434/api/chat http://localhost:11434/v1/embeddings http://localhost:11434/v1/chat/completions兼容接口的存在意义很大：如果团队之前写过接 OpenAI 的代码，只需要把 base_url 改成http://localhost:11434/v1，再改一下模型名，其他调用参数几乎不用动。我自己习惯用原生接口，因为返回结构更直观、字段更少，调试的时候一眼能看明白。
3. 向量数据库 Milvus 的部署与集合初始化
3.1 为什么一定要专门的向量数据库
知识库规模小的时候，比如只有几百条片段，用 Python 列表加暴力遍历也能算出相似度。但这不是一个能生长的方案。当片段数到几千上万条时，每次查询都全量计算向量余弦相似度，延迟会让人无法接受。更重要的是，真实产品还需要持久化存储、增量更新、并发查询、备份恢复，这些都是内存方案解决不了的。
Milvus 的价值在于把向量索引和检索工程化了。它内置多种索引算法，能在大规模向量上实现毫秒级检索，同时还支持元数据过滤、数据持久化、多副本等能力。在客服场景里，它就是那个"知识库档案柜"——写入、更新、按语义取档，一站搞定。
3.2 部署方式选择：本地验证用 Lite，正式部署用 Docker
Milvus 有两种常见部署形态，我根据阶段不同做了区分：
Milvus Lite 是一个 Python 内嵌版本，通过pip install pymilvus之后可以直接在代码里使用，数据落在本地文件目录，不需要额外启动服务。优点是零依赖，特别适合本机开发调试；缺点是性能和功能有限，不适合多进程、多机部署。
独立版 Milvus 通过 Docker Compose 启动，完整架构包含三个核心组件：etcd 保存元数据、MinIO 保存数据文件、Milvus 主服务负责查询和写入。虽然部署文件看起来复杂，但基本都是模板化操作，启动一次之后就不需要再碰了。正式项目建议直接用独立版，后续知识库迁移、扩容都更方便。
一个最小化的启动流程大概是：安装 Docker 和 Docker Compose，然后准备一个 compose 文件，包含上面三个服务的定义，执行docker compose up -d等待容器进入健康状态。Milvus 默认监听 19530 端口，Python 客户端通过http://localhost:19530连接。
3.3 集合 Schema 设计：字段规划与索引参数
集合可以理解成 MySQL 里的表，写入向量之前必须先定义字段结构。我的知识库集合设计如下：
| 字段名 | 数据类型 | 说明 |
|---|---|---|
| id | INT64 | 主键，自增 |
| text | VARCHAR | 原始文本片段，生成回答时作为上下文 |
| source | VARCHAR | 来源文档标识，便于追溯答案出处 |
| type | VARCHAR | 文档类型标签，可用于检索过滤 |
| embedding | FLOAT_VECTOR | 文本向量，维度与嵌入模型一致 |
创建集合要注意两个硬性约束，否则后面会出现莫名其妙的问题：
第一，向量维度必须和嵌入模型输出维度严格一致。我用的 bge-m3 输出 1024 维，schema 里的 FLOAT_VECTOR 维度就必须写 1024。写小了写入报错，写大了检索距离计算失真。
第二，索引类型和相似度度量要提前定好。我选了 HNSW 索引和 COSINE 度量。HNSW 是图结构的近似最近邻索引，检索速度快、召回率高，非常适用于中大规模向量库；COSINE 余弦相似度对文本语义匹配更友好，尤其适合中文短文本问答。
集合创建之后，我建议先手动插两条测试向量，再查询一遍确认链路没问题，再进入批量导入阶段。这个"先通后批"的习惯能帮你把环境问题和数据问题分开排查。
4. 知识库文档处理：从原始文件到 Milvus 入库的完整过程
4.1 多种文档来源的解析与文本清洗
客服知识库的素材来源五花八门：产品说明书是 Word，服务协议是 PDF，常见问题可能是 Excel，还有一些可能是从官网扒下来的网页内容。无论来源是什么，第一步都是把它们变成干净的纯文本。
我遇到过的几种典型情况：
- TXT 和 Markdown 文件直接读文本，基本不需要额外处理；
- Word 和 PDF 需要依赖解析工具提取文本内容，提取出来之后要清理分页符、多余空格、孤立换行符；
- 网页抓取的内容要先去标签、去脚本、去导航文案，只保留正文区域。
文本清洗这一步最容易被忽略，但对后续影响很大。如果文本里混着大量无意义符号和重复的空行，分块之后向量化的效果会被稀释，检索精确度随之下降。我习惯在清洗阶段做三件事：把所有空白符压缩成单个空格、删除明显无意义的字符、统一换行为\n。代码并不复杂，但值得认真对待。
4.2 分块策略：直接整篇入库是新手最容易掉的坑
把整个文档作为一个整体向量化，是几乎所有刚接触 RAG 的人都会踩的坑。一个几百 KB 的 PDF 如果只生成一个向量，这个向量只能表示"这份文档大概在讲什么主题"，完全没有定位到具体答案的能力。用户问"第三章第二节的表格怎么填"，你只给模型"这是一本操作手册"级别的信息，它自然答不出来。
正确的做法是把文档切成固定大小的块。切块有两个关键参数：
- chunk_size：每个块的最大字符数。我常用 512。太短会导致语义信息不完整，检索时召回片段显得零碎；太长则会让一个块里包含多个主题，检索时匹配精度下降。
- chunk_overlap：相邻两个块之间重叠的字符数。我常用 64，大约是 chunk_size 的 12%。重叠的目的在于避免语义被切断。比如一个完整句子被硬生生分成两半，一半在上一块的末尾，一半在下一块的开头，如果没有重叠，这一句就"散架"了，哪块都检索不到完整语义。
如果文档本身已经按章节组织，更好的做法是优先按标题结构切分，在每个章节内部再按长度约束细分。这样切出来的块语义边界更自然，检索命中率会明显好于纯按字符硬切。具体做法是先用标题匹配识别出章节边界，再对每个章节内部的文本做长度切分。
4.3 批量向量化与数据写入的实操代码
分块完成之后，进入向量化入库阶段。嵌入接口的调用方式是通过 HTTP POST 把文本发给 Ollama 的/api/embed，返回的就是文本对应的向量。下面是完整的入库流程：
import requests from pymilvus import MilvusClient OLLAMA_HOST = "localhost:11434" MILVUS_URI = "http://localhost:19530" COLLECTION_NAME = "knowledge_base" def get_embedding(text: str) -> list: resp = requests.post( f"http://{OLLAMA_HOST}/api/embed", json={"model": "bge-m3", "input": text} ) return resp.json()["embeddings"][0] client = MilvusClient(uri=MILVUS_URI) chunks = [...] # 前面步骤得到的片段列表，每个元素包含 text、source、type data = [] for i, chunk in enumerate(chunks): vec = get_embedding(chunk["text"]) data.append({ "text": chunk["text"], "source": chunk["source"], "type": chunk.get("type", "general"), "embedding": vec, }) if (i + 1) % 100 == 0: print(f"已向量化 {i+1} 条...") client.insert(collection_name=COLLECTION_NAME, data=data) print("入库完成，共", len(data), "条")批量插入时有一个性能细节值得提：如果逐条调用嵌入接口，2000 个片段就要等 2000 次 HTTP 往返，很慢。Ollama 的/api/embed接口支持一次传入多条文本，也就是把input参数从字符串改成字符串列表，一次性返回多个向量。我在实际项目中按每批 32 条提交，吞吐明显提升，也减轻了模型的调度压力。
入库之后，别急着写业务代码，先做一次查询验证：
query_vec = get_embedding("如何申请售后") res = client.search( collection_name=COLLECTION_NAME, data=[query_vec], limit=3, output_fields=["text", "source"] ) for hit in res[0]: print(hit["distance"], hit["entity"]["source"], hit["entity"]["text"][:100])看一眼返回的前几条是不是和"售后申请"相关。如果相关，说明链路通了；如果不相关，先检查嵌入模型是否选对、分块是否合理，再检查源文档是否解析出乱码。这一步排查成本最低，等进入问答生成阶段再发现问题就麻烦多了。
5. 客服问答接口实现：检索、Prompt 拼装与 DeepSeek 生成
5.1 检索参数调优：返回条数与相似度阈值
查询侧的第一个关键点是召回参数。用户问题向量化之后，在 Milvus 里做相似度搜索时，有两个参数需要仔细权衡：limit（返回条数）和检索阈值。
limit决定了给大模型喂多少上下文。给太少，可能漏掉正确答案所在的片段；给太多，无关内容会稀释重点，模型还会被带偏。我测试下来，客服场景 3 到 5 条是合理区间。每条按 512 字估算，3 条就是约 1500 字上下文，已经能覆盖绝大多数问题的答案分布。
检索阈值在 COSINE 度量下是一个 0 到 1 之间的浮点数，越接近 1 表示越相似。我习惯设 0.5：高于 0.5 的片段才进入 Prompt，低于 0.5 的一律视为不相关。这个阈值可以看作"宁可漏检，不可误检"的保护阀。弱相关片段一旦混进上下文，大模型很容易"强行找话说"，编一些模棱两可的内容，这比回答"知识库没有相关内容"危害大得多。
5.2 提示词模板的工程化设计
生成阶段的核心是 Prompt 设计。一个合格的客服回答 Prompt，要让模型明确三件事：角色是什么、哪些材料是可信的事实、找不到答案时怎么办。我使用的模板如下：
你是客服助手。请严格基于下面提供的资料回答用户问题。 如果你在资料中找不到与问题直接相关的信息，请直接回答： "知识库中没有找到对应内容，建议联系人工客服查询。" 请勿编造资料中不存在的信息，请勿使用资料之外的知识。 【资料开始】 {context} 【资料结束】 用户问题：{question}这个模板里有三个设计细节：
第一，"严格基于资料回答"是在限定信息范围。没有这句话，大模型会忍不住动用它训练时记住的通用知识，回答虽然流畅但可能和你的产品完全不符。
第二，"找不到就直说"是在给模型留退路。要求模型在信息不足时明确承认不知道，而不是硬编。这一点直接决定客服回答的可信度。
第三，"资料"用单独的分隔符包裹，让模型在输入结构上就能区分"事实材料区"和"用户问题区"，减少混淆。
如果你发现回答仍然跑偏，可以继续往模板里加例子，比如给出一个"资料中没有答案时的标准回复示例"，模型学到的不是抽象规则，而是具体的表达范式，效果往往立竿见影。
5.3 从检索到生成的完整接口代码
把检索和生成拼起来，就是一个完整的问答服务。我用 FastAPI 写一个最小可用的/chat接口：
from fastapi import FastAPI, Request import requests from pymilvus import MilvusClient app = FastAPI() OLLAMA_HOST = "localhost:11434" OLLAMA_CHAT_URL = f"http://{OLLAMA_HOST}/api/chat" OLLAMA_EMBED_URL = f"http://{OLLAMA_HOST}/api/embed" MILVUS_URI = "http://localhost:19530" COLLECTION_NAME = "knowledge_base" def embed(text: str) -> list: resp = requests.post(OLLAMA_EMBED_URL, json={"model": "bge-m3", "input": text}) return resp.json()["embeddings"][0] def search(query_vector: list, top_k: int = 3, threshold: float = 0.5) -> list: client = MilvusClient(uri=MILVUS_URI) res = client.search( collection_name=COLLECTION_NAME, data=[query_vector], limit=top_k, output_fields=["text", "source"], search_params={"params": {"radius": threshold}}, ) return [ {"text": hit["entity"]["text"], "source": hit["entity"]["source"], "distance": hit["distance"]} for hit in res[0] if hit["distance"] >= threshold ] def generate_answer(question: str, contexts: list) -> str: context_block = "\n\n".join([f"[片段{i+1}]\n{c['text']}" for i, c in enumerate(contexts)]) prompt = f"""你是客服助手。请严格基于下面提供的资料回答用户问题。 如果你在资料中找不到与问题直接相关的信息，请直接回答： "知识库中没有找到对应内容，建议联系人工客服查询。" 请勿编造资料中不存在的信息，请勿使用资料之外的知识。 【资料开始】 {context_block} 【资料结束】 用户问题：{question} """ resp = requests.post( OLLAMA_CHAT_URL, json={ "model": "deepseek-r1:7b", "messages": [{"role": "user", "content": prompt}], "stream": False, "options": {"temperature": 0.5}, }, ) return resp.json()["message"]["content"] @app.post("/chat") async def chat(request: Request): body = await request.json() question = body.get("question", "").strip() if not question: return {"error": "question 不能为空"} query_vector = embed(question) contexts = search(query_vector) if not contexts: return { "answer": "知识库中没有找到对应内容，建议联系人工客服查询。", "sources": [], } answer = generate_answer(question, contexts) return { "answer": answer, "sources": [c["source"] for c in contexts], }启动：
uvicorn main:app --host 0.0.0.0 --port 8000请求测试：
curl -X POST http://localhost:8000/chat \ -H "Content-Type: application/json" \ -d '{"question":"怎么申请退货"}'这个接口虽然精简，但已经具备生产客服系统最核心的能力。回答之外还返回了sources字段，方便在客服工作台里展示"该回答引用了哪些文档"，也让后续问题溯源有据可查。
5.4 流式输出的必要性和实现思路
如果你把这个接口直接扔给真实用户用，第一个被吐槽的必然是"响应太慢"。DeepSeek 7b 在纯 CPU 环境下生成 200 字回答可能要 15 到 25 秒，非流式接口要等全部生成完才返回，用户面对一个死等的小菊花，体验极差。
解决办法是启用流式输出。Ollama 的/api/chat接口支持流式模式，把stream设为True，接口会以增量方式返回 token 片段。前端可以通过 HTTP 的流式响应接收这些片段，边接收边渲染，用户在 3 秒左右就能看到首字，等上十几秒也不会觉得卡死。
本地调试阶段，非流式接口更简单、更容易定位问题；正式服务时，再按流式改造。核心逻辑是一样的，只是把一次性的响应体改成一个生成器逐步返回。
6. 实测效果、典型问题排查与经验总结
6.1 我在办公机上的实测数据
我完整跑通这套系统用的是一台无独显办公机：8 核 CPU、16GB 内存，知识库片段约 2000 条。整体耗时分布如下：
| 环节 | 平均耗时 |
|---|---|
| 问题向量化 | 约 0.5 秒 |
| Milvus 检索（top 3） | 约 30 毫秒 |
| DeepSeek 回答生成（约 200 字） | 约 15 到 25 秒 |
| 全链路总耗时 | 约 20 到 30 秒 |
数据说明了一个事实：整个系统的性能瓶颈是文本生成，不是检索。所以优化的重心应该放在模型生成速度上。最常见的优化手段是加显卡把模型放进显存，生成速度可以快几倍甚至十几倍；其次是换成更小的模型，比如 1.5b，但回答质量会明显下降。你需要在质量和速度之间根据自己的预算找平衡点。
6.2 召回结果被无关文档污染的一次排查
项目做到中期，我发现用户问"退货流程"时，回答里总混进来品牌宣传文的内容。排查过程很有意思：向量检索召回结果单独看，每条的距离值都不低，都在阈值以上，但内容就是不对。
后来我把召回片段逐条打出来对比，发现问题出在文档分块上。品牌宣传文章里的长段落被切成了带大量修饰语的块，里面提到"退换无忧""售后贴心"之类的词，和"退货"在语义上有间接关联，被模型误判为相关。这些块本身不含任何操作信息，自然没法支撑一个有效的回答。
解决办法是给每个片段加一个type字段，在检索时用 Milvus 的过滤表达式把品牌宣传类排除掉：
res = client.search( collection_name=COLLECTION_NAME, data=[query_vector], limit=3, filter="type != 'brand'", output_fields=["text", "source"], )这个小改动立竿见影，回答准确率提升不少。这个坑值得记住：当你发现回答内容跑偏时，先别急着怀疑大模型能力，先看召回来的片段是不是被无关内容污染了。
6.3 日常维护的更新策略与问题清单
客服知识库不是一次建完就一劳永逸的。产品功能更新、FAQ 改版、政策变化，都需要同步更新知识库。我采用的是全量重建策略：文档变更后重新解析、分块、向量化，删除旧集合重建新集合。在 2000 条规模下，全量重建只需要几分钟，完全可接受。后续如果数据量上来了，再改成增量更新策略，用文档版本号或者更新时间差来判断哪些片段需要替换。
日常运维中，我给自己列了一个排查清单，遇到问题时按顺序检查：
| 问题表现 | 可能原因 | 排查方向 |
|---|---|---|
| 检索不到相关内容 | 向量维度不一致、嵌入模型错误 | 打印向量维度，确认 bge-m3 是 1024 维 |
| 回答与知识库矛盾 | 检索阈值过低，弱相关片段进入上下文 | 提高阈值，检查返回片段距离分布 |
| 回答过于冗长或跑题 | 上下文塞了太多片段 | 降低 limit，减少冗余片段 |
| 回答中出现编造内容 | 提示词缺少"禁止编造"约束 | 强化提示词边界说明 |
| 首次请求特别慢 | 模型还没加载进内存 | 设置模型驻留参数，提前预热 |
6.4 关于"零成本"我最后说几句实话
这套方案零成本，指的是不用按 Token 付 API 费、没有按调用次数计费、数据全程在本地不出门，可以无限次调试和优化模型效果。但零成本不等于零代价，它有另外两个隐性成本。
一个是硬件资源。普通办公机可以跑，但速度摆在那里。要获得接近商业 API 的体验，至少需要一块中端显卡，这本身就是一笔固定投入。
另一个是维护成本。本地知识库需要有人定期更新文档、排查检索质量、调整提示词，这些工作虽然不复杂，但需要持续投入时间。好在一旦流程跑顺，每次更新就是跑一遍脚本的事，十几分钟就能完成。
对我来说，这套方案最大的价值在于"可控"。数据在自己手里，模型跑在自己机器上，问题可以随时复现、随时调试。对预算有限、又想快速拥有一个自控客服系统的团队而言，Ollama + Milvus + DeepSeek 这条路，是目前我测试下来最省心、性价比最高的一条。
