企业官网建设流程全解析

1. 龙呤AI 1.5 是什么：为什么要在本地跑一套轻量化私有化AI

先把结论放在前面：龙呤AI 1.5 是一套面向本地环境的轻量化智能交互系统，底层用 OCT+DSS+ODP 三个模块把对话编排、状态维护、数据管道拆开，最终交付的是一个数据不出域、模型可控、可离线运行的私有化AI解决方案。我落地这套系统的目标是解决一个很现实的问题：很多企业根本不缺模型API，缺的是“敢把数据喂给外部服务”的胆子——客户资料、财务摘要、内部技术文档，这些东西往云端一放，睡都睡不安稳。

龙呤AI 1.5 的“轻量化”体现在两个层面。第一是硬件门槛低，不追求A100集群，普通工作站、一台16G内存的台式机、甚至一块8G显存的笔记本GPU都能跑。第二是架构轻，不搞微服务全家桶，三个核心模块各司其职，用标准接口对接，单机部署半小时能跑通。这个定位非常适合三类人：需要私有化知识库问答的企业IT团队、做AI应用集成的个人开发者、以及想在内网环境做智能交互原型验证的科研组。

我在设计这套系统时坚持一个原则：能用本地小模型解决的场景，就不调云端大模型。不是因为云端模型不好，而是因为私有化方案的交付边界清晰——权限在我、数据在我、可用率在我。龙呤AI 1.5 的目标不是替代GPT级别的大模型，而是把80%的日常交互场景用7B左右的量化模型稳稳接住，需要更强推理时再通过接口转发到内部高算力节点，这个“先本地、再升级”的路径，比一上来就堆算力务实得多。

整套系统的项目命名里带“龙呤”二字，取的是“龙吟”的谐音，寓意本地AI像龙的低吟一样不张扬但持续有力。1.5版本相较早期版本主要改善了三件事：对话树的可视化配置能力、状态服务的持久化稳定性、数据管道对多种文档格式的兼容性。下面我把架构拆开讲，说清楚OCT、DSS、ODP各自在系统中扮演什么角色。

2. 三大核心模块拆解：OCT+DSS+ODP如何协作

2.1 OCT（Orchestrated Conversation Tree）：对话流程的“总调度”

OCT 全称 Orchestrated Conversation Tree，即编排式对话树，它解决的是“对话该往哪走”的问题。用户说了一句“我要查上季度的项目成本”，系统不能直接把这句原文扔给模型就完事，它需要先判断这属于什么意图、需要进入哪个处理流程、有没有前置条件必须满足，所有这些流程控制逻辑都落在OCT层。

举一个贴近实际的例子。我在龙呤AI 1.5中预设了一个查报表的对话分支：当用户提出“查成本”相关请求，流程会依次经历“意图识别→参数抽取→数据源校验→结果生成→二次确认”五个节点。如果用户说“查上季度项目成本但没写项目名”，对话树会走到“参数补全”这个分支节点，主动反问用户缺少的信息。这种分支处理能力如果用裸模型实现，十个回合里有七个会跑偏，但用树状结构定义之后，每一步都有明确的跳转规则，逻辑完全可控。

为什么采用“树”而不是“链”或“图”？因为树结构对开发者和运维者最友好。链式流程只能一条路走到底，扩展新场景要不断拉长链路，调试时上下文一长很容易互相干扰。图结构灵活但状态管理复杂，杀鸡用牛刀。对话树的每个节点包含三个核心元素：触发条件、处理动作、子节点引用。触发条件用正则或意图分类模型判断；处理动作可以是调用内部函数，比如查数据库、查知识库；子节点引用则决定下一步分支。龙呤AI 1.5默认提供一个基础对话树模板，覆盖寒暄、知识库问答、文档检索、任务指令四类常见交互，实际项目里我会建议各家根据业务场景自己改树结构。

OCT层的实现要关注两个细节：节点超时和兜底策略。用户在某节点停留超过设定时间，系统需要主动提示或退出流程；如果用户输入无法匹配任何意图，则必须落入一个明确的“听不懂”节点，而不是让模型自由发挥。这种兜底策略保证了系统行为可预期，在B端交付时尤为重要。

2.2 DSS（Dialog State Service）：对话记忆的“持久化中枢”

DSS 全称 Dialog State Service，即对话状态服务。如果说OCT是大脑皮层，决定怎么反应，那DSS就是海马体，负责记住这件事前因后果。多轮对话中，用户上一轮提到的“那个项目”“成本明细”这类指代，必须结合历史状态才能正确理解。DSS的核心职责就是维护每个会话的状态快照，并在需要时快速恢复上下文。

龙呤AI 1.5的DSS设计包含四个层次：会话基础信息（session_id、用户ID、创建时间）、交互历史记录（每轮用户输入和系统输出的摘要）、业务状态槽位（已抽取的实体参数、当前所处对话树节点）、临时上下文栈（本次交互周期内模型需要的原始上下文片段）。状态存哪里？单机场景用本地文件或SQLite足够，多实例部署可以平滑迁移到Redis。我在实测中发现，状态快照的序列化策略比存储介质更影响体验——如果每轮对话都全量存所有原始文本，会话一长状态体积就失控，必须设计裁剪策略。

状态裁剪是DSS最难做好的部分。我采用的策略是“摘要+原始片段”分级保留：最近两轮交互保留完整原文，更早的交互由小模型生成摘要后仅存摘要，业务状态槽位单独且永远保留。这个方案让一个20轮的长会话状态体积控制在4K token以内，既保住了关键信息，又不会撑爆模型上下文窗口。任何DSS实现都要考虑状态过期问题：给会话设置TTL，比如24小时无交互自动清理，避免存储无限增长。

2.3 ODP（On-device Data Pipeline）：本地知识库的“数据加工厂”

ODP 全称 On-device Data Pipeline，即端侧数据管道。私有化AI的核心价值在于能够回答私有知识相关问题，而ODP就是让AI“读得懂”私有数据的通道。它负责完成数据从原始文件到可检索向量的整个转换过程：接入文档、清洗内容、切分成块、向量化、写入向量库、建立索引。

龙呤AI 1.5的ODP在数据接入层支持常见格式：PDF、Word、Markdown、TXT、CSV。这里有个最常见的误区：拿到文档直接切分向量化，结果嵌入质量极差。因为PDF表格会被切得支离破碎，Word里的页眉页脚混进正文。我在这套系统里做了一步文档结构预处理——用版面分析把标题、段落、表格识别出来，表格先转成Markdown再切分，页眉页脚直接丢弃。实测下来这一步能把检索命中率提高30%以上。

向量化方案我做了两组对照：用bge-large-zh-v1.5做中文文本嵌入，配合本地的 Qdrant 向量库；对照组用纯关键词BM25检索。结论是向量检索在语义相关性上优势明显，但关键词检索在精确匹配场景（订单号、型号编码）依然有价值。所以龙呤AI 1.5的ODP默认采用混合检索策略：向量检索召回Top50，BM25召回Top20，合并去重后做重排，再截取Top5作为上下文注入模型。这个方案在不同知识集上都表现稳定。

2.4 三个模块如何串成一条完整链路

要理解三者的协作关系，最直接的方式是跟一次完整的用户请求。用户输入“帮我总结一下新来的隐私保护制度里关于数据保存期限的规定”。这个请求进入系统后：

用户输入 → OCT层先做意图识别，判定为“知识库问答”，定位到对应的文档问答分支 → DSS层加载该会话历史，发现用户前一轮问的是“数据分类标准”，于是判断本轮“数据保存期限”属于同一主题下的追问，不是新话题 → ODP层接收关键短语“隐私保护制度”“数据保存期限”作为检索条件，在向量库中执行混合检索，返回相关段落 → 模型结合DSS提供的会话摘要、ODP召回的段落、当前用户问题，生成最终回答 → 生成结果返回给DSS更新状态快照，同时OCT将回答包装成特定话术格式回传给前端。

这条链路中，每个模块都在自己的边界内工作，模块之间通过标准接口通信。这正是拆分架构的最大收益：如果ODP召回效果差，只需优化ODP内部策略，不影响OCT和DSS；如果希望支持新的交互类型，只需在OCT添加节点，不需要重构整个系统。对于一套需要持续迭代的私有化AI系统，这种边界清晰的设计带来的维护收益，远大于短期内“一个脚本全搞定”的效率收益。

3. 从零部署龙呤AI 1.5：模型选型与详细步骤

3.1 本地化模型的选型思路

私有化场景下的模型选型不能只看榜单分数，要看硬件承受极限。龙呤AI 1.5的默认配置选择 Qwen2.5-7B-Instruct 的 GGUF Q4_K_M 量化版本。原因有三：中文理解能力在7B级别属于第一梯队，与常见的私有化知识库场景高度匹配；Q4量化后模型文件约4.7GB，16G内存的CPU机器可运行，8G显存GPU可加速；社区生态完善，推理框架兼容性好。

如果硬件更紧张，可以降级到 Qwen2.5-3B 或 Qwen2.5-1.5B 的量化版本，交互流畅度显著提升，但知识问答的准确性会下降一截。硬件充裕时，升级到 Qwen2.5-14B 的 AWQ 4-bit 量化版本，虽然显存需求提升到约10GB，但回答质量、复杂指令跟随能力的提升非常明显。我给客户的选型建议是：先按最低硬件跑7B量化版把业务逻辑全部调通，再根据预算逐步替换更强模型。模型文件通过Ollama管理，更换模型只是切换一个环境变量的配置，不需要改动代码。

3.2 推理框架选型与硬件配置参考

推理框架我对比过三款：Ollama、llama.cpp、vLLM。Ollama胜在零配置和一键管理，内部兼容llama.cpp，对单机部署最友好，龙呤AI 1.5主推它作为运行时。llama.cpp适合嵌入式或极致轻量场景，可以直接编译成单二进制文件。vLLM的吞吐能力更适合高并发多用户场景，但显存要求更高，部署复杂度也更大。对大多数私有化项目，Ollama是性价比最高的起点。

配套硬件参考表如下：

3.3 完整部署八步走

以下步骤基于Ubuntu 22.04系统、Docker环境、Ollama运行时，按顺序操作即可复现。

第一步：安装基础环境。更新系统并安装Docker、Python 3.10、Git。

sudo apt update && sudo apt upgrade -y curl -fsSL https://get.docker.com | sudo sh sudo usermod -aG docker $USER sudo apt install -y python3-pip git

第二步：部署Ollama运行时。

curl -fsSL https://ollama.com/install.sh | sh ollama pull qwen2.5:7b-instruct-q4_K_M

拉取完成后用ollama list确认模型文件已就位。

第三步：部署向量数据库Qdrant。龙呤AI 1.5的ODP层默认使用Qdrant作为向量存储，单机场景运行消耗约1G内存。

docker run -d --name qdrant -p 6333:6333 -v $(pwd)/qdrant_storage:/qdrant/storage qdrant/qdrant:latest

第四步：构建知识库索引。把企业内部文档放入./data/knowledge目录，运行龙呤AI 1.5自带的ODP索引脚本。假设脚本入口为odp_index.py：

pip install bge-reranker-v2-m3 pymupdf langchain-text-splitters qdrant-client sentence-transformers python odp_index.py --source ./data/knowledge --collection company_kb

脚本会依次执行文档解析、结构清理、文本切分、向量化写入。索引完成后可在Qdrant的Dashboard中看到company_kb集合及向量数量。

第五步：配置DSS状态服务。龙呤AI 1.5的DSS默认使用SQLite本地存储，修改配置文件config/dss.yaml中的状态过期时间：

session: ttl_hours: 24 storage: sqlite db_path: ./data/dss_state.db context: summarize_model: qwen2.5:3b-instruct-q4_K_M recent_rounds_keep: 2

第六步：配置OCT对话树。龙呤AI 1.5提供config/oct_tree.json文件编辑对话树结构，我这里使用默认模板启动，后续按业务需求再调整分支节点。

第七步：启动主服务。docker-compose模式一键拉起API网关、OCT服务、DSS服务、ODP服务：

docker-compose -f docker-compose.yml up -d curl http://localhost:8080/api/health

返回{"status": "ok"}即表示核心服务正常。

第八步：联调验证。用测试请求确认完整链路可用：

curl -X POST http://localhost:8080/api/chat \ -H "Content-Type: application/json" \ -d '{"session_id":"test001", "message":"简要说明今天知识库里有哪几类文档？"}'

返回结果包含回答正文、引用来源、耗时指标，说明龙呤AI 1.5已完整跑通。

4. 性能调优：显存、延迟、上下文的三场硬仗

4.1 显存不够时的优化手段

显存不足是私有化部署最常见的拦路虎。我实测7B Q4量化模型在8G显存机器上，默认配置跑满上下文时会报CUDA out of memory。第一个动作是限制上下文窗口长度，Ollama通过环境变量设置：

OLLAMA_CONTEXT_LENGTH=8192

如果依然爆显存，再降到4096。另一项有效手段是开启 KV Cache 分页策略，Ollama新版本默认支持，可显著减少显存碎片化。如果过程中产生大量并发请求，可在Ollama配置中限制并发数：

OLLAMA_NUM_PARALLEL=1 OLLAMA_MAX_LOADED_MODELS=1

这会让请求排队处理，但避免多模型同时驻留显存导致溢出。

4.2 延迟压不下来的排查思路

CPU推理场景，7B量化模型的生成速度大约每秒3-5个token，回答一句20个token的话需要约5-7秒。想要提速，先调整CPU线程数。Ollama默认自动探测，但自动值往往保守。手动指定：

OLLAMA_NUM_THREADS=8

对CPU推理的提升立竿见影。另外一个容易忽略的细节是模型预热：模型刚加载到内存时，首次请求因为要完成权重加载、图优化，响应特别慢。因此龙呤AI 1.5的健康检查机制会在服务启动后自动发送一个空请求完成预热，这个设计直接把首个真实请求的等待时间从15秒压到3秒以内。

GPU场景延迟高的原因大多是上下文过长。模型需要预填充大量历史token。我建议严格限制注入模型的token数：ODP召回内容、DSS摘要、系统提示词合计不超过模型上下文窗口的60%，预留token用于生成回答。当输入token数量从6000降到3000时，首token延迟能下降约40%。

4.3 知识库检索效果调优，让回答更准

龙呤AI 1.5上线初期，用户反馈“答案驴唇不对马嘴”，九成问题出在ODP的检索质量，而非模型能力。检索优化的第一杠杆是文本切块大小。我做了不同参数对照：

第二杠杆是查询改写。用户原话“数据保存期限是怎么规定的？”如果直接拿去检索，可能匹配不到包含“存储周期”“留存时间”的文档。优化策略是先用小模型把用户问题改写成适合检索的查询短语集合，再并发检索多个短语，合并结果。实测这个方法把Top5命中准确率提升了22%。

第三杠杆是重排序。向量检索召回Top50后用bge-reranker-v2-m3精排，截取Top5。重排会增加约100ms延迟，但回答相关性提升非常明显。这一套“向量粗排+关键词召回+模型精排”的组合，让我在多个知识库项目里都把首答准确率稳定在85%以上。

5. 常见问题与排查实录：我踩过的坑

5.1 六个高频问题速查表

5.2 通过日志快速定位故障环节

龙呤AI 1.5的每个模块单独输出日志，排查时按链路一层层看。用户报“回答不对”，先翻ODP日志，看检索到了哪些段落、重排分数是多少；如果召回内容本身就不相关，问题在ODP；如果召回内容相关但回答依然跑偏，问题大概率在模型上下文拼接或DSS状态注入。用户报“没反应”，先看OCT日志，看意图识别是否生效、请求有没有落到某个节点；再看DSS日志，确认状态读写是否异常。三层日志配合健康检查接口，能快速把70%的问题定位到具体模块。

5.3 独家避坑清单

不要一开始就把所有数据灌进向量库。脏数据不清理，检索效果会被大量无关片段污染，先建小样本测试集跑通链路再全量接入。embedding模型的重要性经常被低估，换一个更强的中文embedding模型，收益比换更大规模的推理模型还明显。DSS状态清理一定要加定时任务，没有TTL机制的状态库会在长稳运行后拖垮磁盘和性能。并发模型加载参数必须按显存实测调整，默认配置不一定适合8G小显存。对话树的兜底节点绝不能省，没有兜底的AI在真实用户面前会暴露大量无法解释的失控行为。

6. 龙呤AI 1.5的落地经验与后续扩展

龙呤AI 1.5作为一套本地轻量化私有化AI方案，目前已经在我个人的多个咨询项目中稳定运行。落地经验中最核心的一条：先定义清楚交互边界，再让模型发挥作用。对话树把交互流程框住，数据管道保证每一次回答有据可依，状态服务让长会话不丢记忆，模型只负责生成语言这个大模型最擅长的工作。三者各管一段，系统整体才稳得住。

针对后续扩展，我的规划是增加模型路由层，让简单意图走小模型、复杂任务走大模型，进一步压缩硬件成本；完善多知识库隔离能力，让不同部门的数据互不可见；加入自动化评测集，每次调整知识库或对话树后自动跑回归测试。最后分享一个个人习惯：无论系统多完善，我都会在每个会话入口放一个“隐私提示”标识，明确告知用户对话记录留存情况——私有化并不自动等于合规，只有把数据使用边界讲清楚，这个系统才值得被信任。