基于OCT+DSS+ODP的本地轻量化智能交互系统：私有化AI落地实践

这两年我一直在琢磨一件事：怎么把大模型从云端“拽”回本地。龙呤AI 1.5就是这套折腾的最终产物——一套基于OCT+DSS+ODP架构的本地轻量化智能交互系统。说白了，它就是一个能干知识库问答、能编排私有化Agent、并且完全跑在你自己机器上的AI方案。如果你正在纠结“公司数据不敢上云”“开源模型怎么落地”“本地知识库怎么才能答得准”，这篇文章应该能给你一套可以直接抄的操作路径。

先解释一下标题里的概念，方便后面展开。OCT全称是On-premise Context Transformer，负责本地上下文理解与对话状态管理；DSS是Domain Semantic Service，负责领域知识库的语义检索与生成；ODP是On-device Data Pipeline，负责把PDF、Word、Markdown这些杂七杂八的文件洗成可检索的向量。这三个组件各管一摊，合在一起就是一套完整的私有化AI解决方案。下面我从设计思路、架构细节、部署实操到故障排查，把整个系统的里里外外都拆开讲清楚，文章比较长，建议先收藏。

1. 整体设计与思路拆解

1.1 为什么非要做“私有化”才行

先说个真实场景：一家做医疗器械的客户，手里有几百份产品文档、维修手册和质检规范，想搞个AI助手帮工程师查故障码。方案提了两个：一是调云端大模型API，二是本地私有化部署。业务部门一听“云端”就直接摇头——文档里包含设备内部结构参数，自己人都要签保密协议，怎么可能把数据传到外面去。

这不是个例。企业大模型私有化部署在2025年已经成了刚需，尤其金融、医疗、政务、制造这几个行业，数据不出域是红线。市面上流行的方案很多，workbuddy这类协作工具可以做私有化部署，WPS Comate也支持内网环境，但如果你想要一套自己能完全控制、能改逻辑、能接内部知识库的AI系统，还是得自己搭。

而龙呤AI 1.5的定位恰好卡在这个位置上：它不是对标云端GPT那种超大参数模型，而是用开源基础模型（比如Qwen系列、ChatGLM系列，或者Llama的量化版本）加上本地知识库管道，构建一个比通用API更懂业务、比私有云方案更轻的交互系统。整套东西跑在一台消费级显卡的机器上，而不是动辄几万元的推理服务器。

1.2 轻量化：在“性能”和“能落地”之间找平衡

做这套系统之前，我先明确了一个原则：绝不追求大参数。很多团队一上来就部署70B的Llama，显卡得插四张A100，内存要几百G，采购审批流程比写代码还长。实际跑下来，大部分企业的知识库问答场景，7B到14B的量化模型完全够用。

这里要解释一下“量化”是什么。模型训练完是FP16精度，一个70B模型光权重就要140GB显存。量化就是把浮点数压缩成INT8甚至INT4，显存占用直接减半再减半。虽然会有轻微精度损失，但通过后面讲到的DSS语义检索 + OCT上下文重构，可以把损失补回来，实际回答质量不会比云端大模型差太多。

龙呤AI 1.5的默认配置是：Qwen2.5-14B的INT4量化版，运行在24GB显存的显卡上，同时并行跑OCT、DSS、ODP三个服务。整机功耗大约350W，放在工位旁边能当暖气用，上架到机房2U机箱也没问题。

注意：这里的“轻量”是指整套系统的最小可用配置，而不是模型本身能力弱。如果你想跑更小的7B模型，把上下文长度和检索阈值稍微调一下，也是可以的，下面会详细讲。

2. 核心架构：OCT、DSS、ODP 各管哪一块

2.1 OCT：本地上下文引擎，负责“听懂人话”

OCT是整个系统的入口，核心职责有三块：把用户输入转换成结构化的意图和参数，维护对话历史的上下文窗口，以及把系统的回复组织成符合场景的格式。

很多人以为这活很简单，不就是调个API吗？实际上没那么轻松。比如用户问“帮我把上个月维修记录里提到的电机故障统计一下”，这个句子里有时间范围（上个月）、数据源范围（维修记录）、实体（电机故障）、操作类型（统计），OCT需要把这四类信息全部抽取出来，交给后面的DSS去执行。

我实现OCT时没有直接用大模型做全量推理，而是前置了一个“意图规则层”：先用轻量级规则匹配常见句式，比如“查一下”“统计”“对比”“为什么”这类动作词，匹配不上再走大模型。两块并行跑，规则层处理的请求延迟在200毫秒以内，大模型兜底的请求延迟在1到2秒，整体体验很流畅。

上下文窗口管理也是OCT的绝活。大模型的输入长度是有限的，不能把所有历史记录都塞进去，得做“滚动窗口 + 关键信息持久化”。比如用户半小时前问过“A型号和B型号的区别”，现在又问“那C呢”，OCT会在持久化上下文里找到此前提到的A和B实体，自动补全为“A、B、C三个型号的区别”，而不是让模型瞎猜“C”指什么。

我是曾深度参与过龙呤AI早先版本开发的成员之一，这里可以多说一句：OCT的上下文持久化并不复杂，用一个SQLite表存session_id、实体、意图、时间戳就行，查询的时候按时间倒序取前N条，再拼到提示词里。真正麻烦的是实体消歧，比如“苹果”到底是水果还是品牌，得靠DSM的领域词表去约束。

2.2 DSS：领域语义服务，负责“专业”

DSS是这套系统里最能体现“私有化”价值的部分。它管两件事：知识库的向量化存储，以及检索增强生成（RAG）。所谓RAG，就是对于用户的每个问题，先从知识库里检索出最相关的几段文本，连同问题一起交给大模型去组织答案，而不是让模型凭空发挥。

DSS的检索链路是这样跑的：

1. 用户输入经过OCT意图识别后，生成检索query，并把“上个月”“电机故障”这些限定词拆出来。
2. 检索阶段同时跑两个通道：一个是向量相似度检索，用bge-m3嵌e句模型把query转成向量，在Milvus里做近似搜索；另一个是关键词检索，用ES分词匹配“电机”“维修记录”等词。
3. 两个通道的结果做一个融合排序，属于业界常说的RRF策略（Reciprocal Rank Fusion），最后再过一个rerank模型，按相关性得分取Top 5。

举个例子，问“电机温度超过90度会怎样”，向量检索可能召回到“电机热保护阈值90±5℃”，关键词检索可能召回到“运行环境温度要求”。光靠任意一个都有漏网，融合之后基本就全乎了。

我还给DSS做了一层“置信度校准”。如果检索Top1得分低于预设阈值（比如0.6），DSS不硬答，而是回一句“这个问题在现有知识库中暂时没有找到直接相关资料，建议联系设备厂商确认”，避免一本正经地胡说八道。这一条在私有化场景里特别重要——AI答错技术参数是要出事的。

2.3 ODP：本地数据管道，负责“喂料”

ODP负责把企业里各种各样的文档变成DSS能用的知识库。这步在系统启动文档里往往被一笔带过，但实际踩坑最多。

文档解析这一关就不省心。PDF分两种：文本型PDF可以直接提取文字，扫描型PDF要先OCR。Word要区分doc和docx，老版本的doc文件处理起来兼容性问题不少。表格怎么处理也是难点——直接按单元格拆会丢失行文关系，我最终采用的方案是把表格转成Markdown格式的文本块，再映射成向量，问答“第三季度KPI完成率”这类问题时准确率高很多。

切片策略也有讲究。固定500个字符切一刀，语义被截断；切太长，DSS检索噪声变大。我跑了几十组对照实验，最终用的是“分层切片”：先按文档结构切出段落，段落超过300字再按句号边界细分，保留标题层级作为元数据。这样既保住了语义完整性，又不会让单个切片容量失控。

ODP还有个增量更新的机制。企业文档不是一次性导入就完事，每周都会有新文件。ODP通过文件hash识别新增和变更，变更的文件自动重新切片和向量化，旧的向量在Milvus里标记废弃。整个流程可以挂定时任务，凌晨两点自动跑。

2.4 三模块协同：一个请求的完整旅程

一个请求走完全链路大概是这样：

用户输入“最近一批退换货原因分析”→ OCT做意图识别和实体抽取（动作：分析，对象：退换货原因，时间：最近一批）→ ODP确认知识库里“退换货报告”文件已是最新且已向量化 → DSS检索相关段落（召回“外观划痕”“配件缺失”“包装破损”等）→ 大模型基于检索内容生成结构化报告 → OCT把答案拼上“数据来源：2025年3月售后汇总表第2、7条”之类的引用标注 → 返回给用户。

整套流程看起来多，实测端到端延迟在3到5秒之间，其中大头是大模型生成时间。相比纯云端API，多了一两秒，但换来了数据绝对不出内网，这笔账怎么算都划算。

3. 实操过程：从零部署龙呤AI 1.5

3.1 环境准备清单

部署之前，先把硬件和软件环境说清楚。我这边实测的基准环境如下：

这套配置的整机成本在2万上下。如果预算紧张，可以把模型换成Qwen2.5-7B-INT4，12GB显存的卡也能跑，只是上下文分析和长文本生成能力会弱一些。

软件层面，我建议直接用Docker Compose编排。三个服务各一个容器，再加上Milvus和MySQL，一共5个容器，机器重启之后一条命令全部拉起来。

3.2 模型选择：别总盯着Llama一家

说到开源模型，行业内绕不开Llama。Llama 3系列的整体能力确实强，中文支持也比前代好，但如果你面向的是国内企业知识库问答场景，我会倾向国产模型。Qwen系列的中文指令跟随能力更好——切片后的专业术语召回更准——ChatGLM也有不少团队在用。从部署难度看，Qwen的GGUF量化版本生态最全，vLLM和llama.cpp都支持得很顺。

龙呤AI 1.5默认选用的是Qwen2.5-14B-Instruct的预算配备。选14B而不是7B，是因为在“内部文档问答”这种专业场景里，14B对复杂指令和长上下文的把握明显更稳。选Instruct版而不是Base版，是因为它已经经过聊天对齐训练，部署后不用再费劲写大量few-shot示例。

模型文件从合规渠道下载之后，做一遍“冒烟测试”：丢几个已知答案的问题进去，看输出是否稳定命中，同时测一下显存峰值，确认量化格式和推理框架是匹配的。这一步很关键，很多部署失败的源头都是模型文件与推理引擎版本不兼容。

3.3 服务编排：一条命令拉起全部组件

部署流程我用文档记录过一遍，这里直接放核心步骤。

第一步，准备目录结构：

mkdir -p lomyai/{models,data/knowledge,docker/oct,docker/dss,docker/odp}

第二步，写docker-compose.yml，要点是OCT和DSS都要能访问GPU：

services: oct: build: ./docker/oct ports: - "8001:8001" volumes: - ./data/session:/app/session deploy: resources: reservations: devices: - driver: nvidia count: 1 capabilities: [gpu] dss: build: ./docker/dss ports: - "8002:8002" volumes: - ./models:/app/models - ./data/knowledge:/app/knowledge environment: - INDEX_HOST=vecdb vecdb: image: milvusdb/milvus:v2.4.0 ...

第三步，启动服务：

docker compose up -d

OCT和DSS接口起来之后，在配置文件里把服务地址互相填上。这一步需要改的核心配置项有：OCT的context_max_tokens（建议设置为2048）、DSS的top_k（默认5）和similarity_threshold（默认0.6），以及ODP的schedule（定时扫描周期）。

注意：Docker容器里访问GPU要装NVIDIA Container Toolkit，没有它你会看到could not select device driver "" with capabilities: [[gpu]]这种报错。安装命令很简单，网上到处是教程，但如果你用的是WSL2，还需要在Windows侧把CUDA驱动更新到位。

3.4 知识库冷启动：从零到可以回答问题

服务起来只是第一步，真正让系统“会干活”的是ODP的冷启动过程。

假设你手上有一批企业内部文档，比如操作手册、维修指南、验收规范。冷启动流程一共四步：

第一，把文件丢进data/knowledge目录，支持pdf、docx、md、txt、csv这几种常见格式。第二，ODP自动扫描，完成文本抽取、清洗、去重。清洗这步要处理一堆问题，包括页眉页脚、页码、网址、乱码字符，都得过滤掉。第三，按前面讲的分层切片策略切块，每块附带来源文件、章节路径、页码元数据。第四，用嵌入模型批量转成向量，写入Milvus集合，然后刷新DSS的检索索引。

量大的时候（比如100份文档、50万字符），冷启动可能耗时半小时左右。这期间DSS服务会标记为“索引构建中”，部分检索请求自动排队。建议首次冷启动选在业务低峰期，或者用ODP的异步任务队列错峰执行。

冷启动完成后，我习惯随机抽10个业务真实问题去验证召回效果。比如“设备开机后异响是什么原因”“售后保修期怎么计算”，逐条检索看Top5切片是否相关。如果某些问题的召回段落不理想，优先检查切片策略——这种情况多半是文档段落太大，被切碎后语义丢失了。

4. 知识库问答与私有化Agent落地实践

4.1 把知识库问答的准确率从60%提升到90%

做RAG最怕的就是“答非所问”。我这套系统在实际调优过程中，总结了几个立竿见影的参数调节方案。

先看召回。DSS有个关键参数top_k，取5还是取10差别很大。业务文档少就取5，避免引入噪声；文档库大、题目包含大量近义表达的时候就取10，宁可多召回再靠重排过滤。阈值这边，0.55到0.75之间是需要重点调试的区间，太低会放进来一堆弱相关片段，太高又容易漏掉关键答案。

其次是重排模型。初期我直接用向量相似度排序，结果经常把“相似但是不是答案”的段落排到第一位。后来接了一个cross-encoder重排模型，对“问题和段落”做一个二分类打分，排行结果准确了很多。这套组合在业务测试集上把Top1命中率从62%提到了89%。

还有提示词模板，这步是新手的盲区。DSS给大模型生成的提示词不能是“根据知识库回答问题”这种大白话，要写清楚角色、范围限制、格式要求、引用规则。我常用的模板结构是：

1. 系统角色设定（你是某公司的售后技术专家）
2. 回答要求（只能基于给定片段作答，不能自行发挥）
3. 输出格式（分点列出，附引用来源）
4. 片段内容（占位符）

实测同一个知识库，换了提示词模板，主观评价和自动评分都能涨10个百分点。我把这套模板缓存成版本，每次微调都记录效果评分，跑了一个多月后沉淀出三个迭代版本。

4.2 私有化Agent：让AI不只会问，还会操作

光做问答，充其量是个“高级检索工具”。龙呤AI 1.5的另一个重要功能是把DSS的检索能力和OCT的行动规划能力串起来，形成可以落地的Agent。

什么叫Agent？举个例子：“帮我把本周质量日报发给各个产线负责人”。任务拆分下来是：调OCT的意图识别，发现动作是“发送”、对象是“质量日报”、收件人是“各产线负责人”；调DSS检索出质量日报生成规则和产线负责人名单（这些是知识库内容）；调外部系统MCP接口生成日报并发送；最后向用户确认结果。

这四条链路，前两条走龙呤AI的内部服务，后一条通过标准MCP协议对接企业的OA系统。我建议先把MCP定义好——工具清单、参数schema、权限级别是必需的。Agent每次执行外部操作之前，都要过一遍权限判断，高危险操作如删除数据、发起转账，必须二次人工确认。

私有化Agent还有一个天然优势：你的业务流程、组织架构、数据字典都掌握在手里，不会像云端Agent那样经常出现“找不到对应企业信息”的尴尬。配合OCT的持久化上下文，Agent还能记住用户偏好，例如有的工程师喜欢“先说结论再给依据”，有的喜欢“附上全部原始数据”，这些都会在Session里沉淀成个人配置。

4.3 效果评估：别让“我觉得还行”蒙混过关

龙呤AI迭代到现在，我坚持每版必做效果评估。方法很简单，准备一个业务问答评测集，不少于100条，覆盖高频问题、边界问题、易混淆问题三类。每条标注标准答案或关键要点。评估时跑一遍批量推理，用三项指标看结果：

• 回答相关性：人工打分，1到5分制，看有没有答偏
• 引用准确性：检查回答引用的切片是否真的支持结论
• 召回覆盖率：正确答案对应的知识是否出现在召回集合里

跑完一轮，把失败案例集中过一遍。我的经验是：70%的失败案例是知识库切片问题，20%是提示词模板约束不够，只有10%是模型本身能力不够。所以调优的顺序应该是先调ODP数据，再调DSS模板，最后才考虑换大模型。

5. 常见问题与排查技巧实录

5.1 部署与运行问题速查表

这里面我觉得最值得关注的是“两次回答不一样”这个事。很多使用者一开始会觉得AI“敷衍或抽风”，其实在知识库问答场景里，答案稳定性极度重要。我后来把DDS和OCT之间的传输参数调成固定种子（seed=42），再把temperature压低，回答基本能保持措辞一致。

5.2 我踩过的几个坑和一些小建议

第一坑：中文路径乱码。ODP处理文档时，文件名带着“（终版）.docx”这种全角字符，解析进程在Docker容器里直接炸掉。排查了半天才发现是locale没设好，后来统一在容器环境里加上LANG=zh_CN.UTF-8，文件名预处理时做一次Unicode规范化，才彻底解决。

第二坑：并发下的Session串线。以前OCT用内存字典存session_id，并发一上来，两个用户的问题会在上下文窗口里互相污染。后来迁到Redis缓存，并给每个session加锁，这里的教训是局部变量天然无法支持服务实例扩容。

第三坑：ODP不定时更新导致检索索引和文档不同步。用户明明上传了新文档，问出来的答案还是旧的。原因是Milvus集合的删除操作没有做“软删除标记”，旧的向量还留在索引里。后来改了机制：每次增量更新都带上文档版本号，检索结果必须过滤掉非最新版本。

给新上手的朋友建议是：第一次部署别贪多，先把“ODP导数据 → DSS检索 → OCT问答”这条最小链路跑通，再逐步加Agent、加外部系统对接。每个环节都用真实业务数据去验证，不要用“今天天气怎么样”这种测试来验收。

提示：日志强烈建议统一收集，我用的方案是Filebeat + Elasticsearch，系统的问题是排查得出来的，真正难查的是没有日志的问题。特别是OCT调用大模型超时的根因分析，有完整链路日志才能快速定位。

6. 写在最后的经验之谈

从开始折腾龙呤AI这套系统到现在，最大的感受是“私有化AI没有捷径”。别指望一个开源模型下载下来就能替代所有业务系统，也别指望花一晚上部署就能让所有问题迎刃而解。核心思路永远是：用OCT管好上下文，用DSS管好专业知识，用ODP管好数据质量，三者的配合比单一大模型的参数大小更重要。

我个人最满意的一点是这套系统彻底跑在了内网里，从模型到向量库再到对话日志，干干净净地驻扎在自己机器上。数据这个东西，放在自己手里和放在别人手里，踏实感完全不一样。如果你也正准备做企业级知识库问答或者私有化Agent，我的建议是从龙呤AI里的这套架构思路入手，先盘清自己的数据，再谈模型部署。

最后分享一个使用体验上容易被忽视的细节：把常用问题命中后的答案缓存起来，比如行政制度、报销流程这类几乎不变的内容，OCT配一个快速缓存层，点击即达的回答体验会远超单纯走大模型推理。很多试用者对比后感受明显，马上就会追问你是怎么把延迟做到这么低的。

往后的扩展方向也很明确：接入更多外部工具协议、支持多模态文档的解析、增加基于反馈的在线调优。这套架构的底座已经定下来了，后续迭代就变成了往管道里填更多领域知识。希望这份记录对正在做类似项目的朋友有帮助。