以前给客户做运维平台的时候最让我头疼的不是系统崩溃是工单区每天被二三十条我密码忘了怎么办系统登不上去的重复提问刷屏。挨个回复吧浪费时间不回复吧用户满意度又往下掉。后来我干脆把工单系统和问答机器人打通用户提交问题的时候系统先自动识别意图、从知识库抓答案顺带把工单分类和紧急度都填好再决定是直接回复还是转人工。整个方案的核心就两个词低代码 大模型低代码管流程、页面和权限大模型管理解、分类和生成回复。这套思路让我用大约两周的业余时间搭完了一个能自动问答、自动分派、还能不断补充知识库的智能工单系统。这篇就完整拆解一下我是怎么从零搭出来的适合预算不多、又不想从零写表单和流程引擎的团队也适合想了解大模型怎么真正落到业务里的人。1. 方案设计与技术选型1.1 需求拆解智能工单系统至少需要哪些能力工单系统的本质不是记录一条反馈而是把问题在正确的时间送到正确的人手里。刚开始定制需求的时候很容易把功能想得特别大什么智能客服、自动处理、多轮对话全都加进来。我最后只保留了四个核心能力第一个是信息收集用户从网页表单、小程序或者企业微信提交问题系统要能用结构化字段记录标题、描述、联系方式、附件这些基础信息。第二个是自动分类与路由大模型读完问题后判断类型比如是账号问题、支付问题还是网络问题然后按规则分给对应负责人。第三个是知识库问答对于常见问题系统直接检索知识库生成答案并给出置信度如果足够高就原路回复。第四个是人工兜底所有拿不准的工单自动进人工池客服在后台能看到AI建议回复和分类依据。为什么需要这四件事因为只做自动问答而不做路由只是省掉了客服打字的时间只做路由而不做知识库问答又没有真正减少人工处理量。它们是配合起来才能起作用的。而且工单数据来源通常非常杂有客服电话转写的文字、有网页留言、有IM里的碎片消息大模型在这里的价值就是把非结构化文本清洗成结构化字段减少人来阅读的成本。1.2 为什么选择低代码 大模型而不是纯手写早期方案评审的时候团队里有人提议直接用 Spring Boot Vue 自己写一套认为这样可控性最高。这个想法本身没问题但我算了一笔账就没再犹豫一套带工单流转、角色权限、审批流、附件管理、消息通知的后台即使不用大模型纯手写至少要一到两个月而其中一半的代码是在重复做别人早就做好的事情。低代码平台把表单设计、流程编排、权限分配这些基础设施全都包了我只需要把精力放在智能这一层。大模型则补上了低代码做不了的部分。低代码平台擅长处理结构化数据和固定流程但不知道客户说登录时一直转圈到底是什么意思。而大模型擅长理解语义、抽取关键信息、生成回答但它不擅长做严谨的状态流转和数据关联。所以两者不是竞争关系是天然互补。我这次选型的原则就是一切有固定规则的功能尽量用低代码一切依赖语义理解的功能尽量用大模型边界非常清晰。还有一点需要提醒纯手写意味着后续每次加业务逻辑都要发版而低代码平台的规则修改往往改完立即生效。对于小团队来说这个灵活性比想象的更重要。1.3 平台与模型选型建议低代码平台这一步我对比了宜搭、简道云、明道云这几家常被提到的产品。考虑到后面要大模型接口回调重点看的是两个能力是否支持 HTTP 请求类型的集成自动化或自定义连接器以及普通表单/流程是否支持自定义按钮触发的服务端逻辑。平台表单与流程外部API调用适合场景宜搭完整和钉钉打通支持自定义连接器与集成自动化企业内部工具已有钉钉组织架构简道云完整操作上手快支持 API/Webhook 触发需要灵活接外部服务的团队明道云流程能力强支持自定义API和代码块复杂业务规则希望低代码内写逻辑大模型这边我分了两种路线。如果你只是验证想法直接用云端 API 就行主流大模型 API 的文本理解能力完全够用成本也不高。如果你有数据保密要求或者想长期压低调用成本就走本地部署方案用 Ollama 或 vLLM 跑开源模型。Embedding 模型我推荐 BGE-M3它综合能力在开源里属于第一梯队中文效果好而且支持稠密检索、稀疏检索、多向量三种方式后续做 RAG 召回时可以灵活适配。向量库小规模用 Chroma 足够规模大了换 Milvus。我这次实际用的组合是简道云做表单和审批流FastAPI 写问答服务通义千问 API 做文本理解BGE-M3 做向量化Chroma 做知识检索。2. 大模型与知识库接入细节2.1 模型调用方式的取舍API还是本地部署这一段是不少来问我的朋友卡得最久的地方。先说我自己的判断标准项目上线后每天调用量大概多少、响应时间要求多少、数据隐私边界在哪、团队有没有 GPU。如果每天调用量在几千次以下用 API 最划算省去运维成本而且模型能力天花板明显更高。如果系统要处理客户隐私数据或者调用频率高到每月 API 账单肉疼再考虑本地部署。本地部署到底需要什么配置很多人的误区是没有 A100 就别想跑大模型。实际上用量化后的 7B 模型推理占用的显存大概 56GB你 16GB 显存 32GB 内存的机器完全跑得动响应速度也基本够用。关键是选对量化精度Q4_K_M 在质量和资源占用之间最平衡。我测试过 32GB 内存的纯 CPU 机器也能跑但单次推理要几十秒只适合离线批量处理不适合在线工单问答。API 调用也要考虑一个隐藏问题默认超时时间。低代码平台调的 HTTP 节点一般只有 10 到 30 秒大模型在高峰期完全可能几秒才返回所以要么把超时时间调大要么用异步任务轮询结果。后面在联调部分我会细说处理方式。2.2 RAG让大模型真正懂你的业务直接把工单问题丢给裸模型它只能给你一个看起来正确但没啥用的通用回答因为模型没学过你公司的退款政策、产品报错代码和内部流程。让大模型真正懂业务的常用手段就是 RAG即检索增强生成。RAG 的基本流程是先把业务文档按语义切块比如每个段落控制在 200500 字太长了召回就不准然后对每块做 Embedding把向量存进向量库收到用户问题时再把问题向量化在库里做相似度检索取出最相关的几段最后把用户问题 检索到的业务片段一起拼进 Prompt 给大模型让它基于这些材料回答。这里有两个关键参数值得关注一是召回数量我一般 top_k 取 4 到 6 段太少回答缺乏上下文太多又容易引入噪音二是相似度阈值低于阈值的检索结果宁可不用。第一次搭建时踩过不少坑最典型的就是检索到一堆无关文档导致生成结果更差后来我统一用了标题正文拼接成一条向量再入库效果比单纯切正文要好得多。另外注意不是所有工单内容都适合进向量库。FAQ 类、政策类、操作手册类是首选涉及具体某个用户的个性化数据千万别往向量库里塞既有隐私风险检索价值也不大。2.3 智能问答的Prompt与上下文设计调用大模型最容易犯的错就是问一句帮我分类一下就完事了。实际生产环境里Prompt 就是你的程序代码写得越严谨返回结果越稳定。我给工单系统设计了三个核心任务意图分类、要素抽取、回答生成。分类任务的 Prompt 要点是明确给出所有候选分类以及每个分类的定义并要求只输出分类 ID。比如账号类包含密码找回、登录失败、账号锁定订单类包含未支付、退款、物流查询否则模型容易按自己的理解创造分类名称。要素抽取则要指定抽取哪些字段比如紧急程度、用户情绪、问题类型、涉及的业务模块并要求字段缺失时输出 null不要编造。我基本上都会要求模型返回严格 JSON并在 Prompt 里写明输出格式。同时为了保险程序里还要增加一层正则抽取逻辑万一模型夹带了多余说明文字也能把 JSON 主体扒出来这个防御手段在实际调用中非常重要。3. 低代码平台搭建工单主流程3.1 数据表设计与表单配置低代码平台里建表单是相对简单的但数据表设计决定了后续的智能流转是否顺畅。我的工单主表字段分成三组。第一组是用户填写的原始信息工单标题、问题描述、联系方式、附件第二组是智能引擎生成的字段问题分类、紧急程度、AI 建议回复、置信度、完整 JSON 记录。第三组是流程字段当前处理人、工单状态、处理结果、满意度评价。这里有个很重要的设计理念AI 生成的字段和用户提交字段分开存不要混在一起。一方面方便回溯另一方面避免大模型偶尔出错污染原始数据。完整 JSON 记录我用一个文本字段直接存原始返回万一后面要排查问题能直接看到模型当时到底返回了什么。表单交互上我用的是先提交后智能填充的思路。用户提交表单时只看到基础字段提交成功的同时触发集成自动化调用模型服务然后系统自动更新分类、紧急度这些智能字段。这样用户侧完全无感知客服后台看到的是已经结构化好的数据。3.2 工单流转与规则引擎配置工单流转我设置了四段状态待处理、处理中、已解决、已关闭。每条工单创建后默认是待处理但具体转到谁手里由大模型返回的分类和紧急度决定。低代码平台的流程节点里可以配置根据字段值选择处理人我需要在流程里写判断条件如果分类为账号类节点转给账号组如果分类为订单类转给订单组。为了提高自动化程度我还把紧急度映射成了处理时限高优先级要求 1 小时响应普通要求 8 小时超时自动推送一条提醒给负责人。这里想特别强调不是所有工单都适合完全自动派单。我在流程里加了一个分支节点当置信度低于 0.7 时工单不自动分配给具体负责人而是进入待人工分拣队列由客服主管手动拍板。这个兜底策略在实际运行中非常关键因为模型再强也会有判断错的时候保留一个出口比追求百搭更稳妥。3.3 低代码如何承接大模型返回低代码平台与大模型的接口对接是整体方案里最容易出问题的地方但也最不复杂。逻辑很简单在流程里配置一个 HTTP 节点请求方式选 POST请求体里面带上工单标题、描述等字段发到你的问答服务接口然后拿返回值里的字段去更新当前工单。在配置这种集成自动化时需要特别注意三点。第一是超时设置头部模型服务必须设置合理的超时上限网络波动时要能优雅降级不能因为模型服务不通就把整个提交流程卡死。第二是失败处理无论什么原因导致模型调用失败都不能让用户工单丢失。我用的方案是为容器专门配置了一个暂时的pending_status让工单先进入人工池同时留下标记方便事后重试比直接报错要优雅得多。第三是字段映射低代码平台里返回体通常是一个嵌套 JSON需要用点号路径把嵌套字段取出来先在小范围试跑一次确认能正确解析再发布比发布后反复试错成本低得多。4. 完整实战流程4.1 准备模型与知识库第一步永远是准备知识库不是写代码。我从客服团队要来了最近三个月高频提问记录整理成大约 180 条 FAQ按照账号、支付、订单、使用教程、其他五个分类归档成 CSV。每条记录包含标准问法、标准答案、关联业务部门。然后是文档切分和写入向量库。FAQ 内容不可能全篇塞给模型我按条目切分同时把分类信息合并进文本。接着用 BGE-M3 生成向量写入 Chroma。这个小规模的检索库我全部准备过程也就两小时但整个智能问答的效果全看这一步有没有做好。如果你手头有长文档一样的方式可以迁移到实际场景去处理。比如把产品说明书按 Markdown 标题分块每块再按语义截断配合一个小工具就能完成。我在实践中总结的原则是宁可每块短一点、数量多一点也不要用动辄上千字的长文本因为向量检索的精度会明显下降。4.2 搭建问答服务问答服务我用 FastAPI 写了两个接口。一个是/classify负责对工单做分类、紧急度判断、要素抽取一个是/query负责从知识库检索并生成回复。两接口都返回 JSON。核心示例代码如下我做了删减只留主干逻辑from fastapi import FastAPI from pydantic import BaseModel import requests import json import re app FastAPI() OLLAMA_BASE http://localhost:11434 MODEL qwen2.5:7b # 假设已预先把FAQ写入Chroma并持久化 from retrieval import search_faq class TicketIn(BaseModel): title: str description: str def llm_chat(messages: list) - str: payload { model: MODEL, messages: messages, stream: False, options: {temperature: 0.1} } r requests.post(f{OLLAMA_BASE}/api/chat, jsonpayload, timeout60) r.raise_for_status() return r.json()[message][content] def extract_json(text: str) - dict: # 用更加稳健的正则寻找 JSON 块 match re.search(r\{.*\}, text, re.S) if not match: raise ValueError(no json found) return json.loads(match.group()) app.post(/classify) def classify(ticket: TicketIn): prompt f 你是工单分类引擎只能输出JSON不能输出额外文字。 工单标题{ticket.title} 工单描述{ticket.description} 要求根据以下分类集合给出结果返回格式如下 {{ category: account|payment|order|guide|other, priority: high|medium|low, summary: 一句话概括问题, confidence: 0.0 }} raw llm_chat([ {role: system, content: 你是一个严格的分类器。}, {role: user, content: prompt} ]) return extract_json(raw) app.post(/query) def query(q: dict): question q.get(question, ) docs search_faq(question, top_k4) context \n\n.join([d[text] for d in docs]) prompt f 基于下面的知识库内容回答问题如果知识库中没有相关信息请明确说知识库中暂无此答案如需人工支持请提交工单。 知识库内容 {context} 用户问题{question} raw llm_chat([ {role: system, content: 你是企业知识库助手。}, {role: user, content: prompt} ]) return {answer: raw, source_docs: docs}服务起来之后我用 curl 做了简单验证curl -X POST http://localhost:8000/classify \ -H Content-Type: application/json \ -d {title:登录不上,description:我的密码改了之后一直登录不上一直显示账号锁定}返回结果类似{category: account, priority: high, summary: 用户修改密码后账号被锁定无法正常登录, confidence: 0.95}。这一步验证通过后面低代码就只是一个对接动作而已。4.3 联调从前端提交到自动分单全链路联调是整个项目里最能看到效果的环节。完整链路是这样的用户在表单页面填写工单并提交-低代码平台生成一条新工单记录-集成自动化自动调用/classify接口-模型返回分类、紧急度、置信度-低代码按规则更新工单字段并自动派单-客服后台看到已经分类好的工单和 AI 建议回复。整个过程在用户端没有任何感知他填完表松开手问题就已经在正确的队列里等候处理了。我第一次联调时发现一个实际体验问题用户点击提交到工单出现在后台中间会有三到八秒的等待时间原因是模型接口响应较慢。虽然不影响最终流程但用户体验一般。后来改成立即返回工单创建成功后台异步调用模型处理前端秒回智能填充在后台完成体验好了许多。低代码平台的发起流程和定时触发配合使用就能实现这种异步模式建议你在设计时就考虑进去。5. 常见问题与排查技巧5.1 常见报错与排查我把我实际遇到过的典型问题整理成一份速查表如果你也在搭可以直接对着排查现象原因解决方案低代码调用模型接口超时模型推理速度慢连接器超时时间太短将超时时间调到 30 秒以上更建议改为异步任务模式返回 JSON 偶尔解析失败模型在 JSON 外夹带注释或说明文字Prompt 强约束 正则提取 JSON 块 失败时走人工兜底向量召回结果与问题无关文本切块太长或信息混在不相关段落缩短切块长度标题内容拼接成单条向量排查阈值设置本地部署显存不足模型体积超过显存容量使用 Q4_K_M 量化或用 Ollama 自动部分卸载至CPU运行模型总是返回过时答案知识库更新未重新生成向量建立文档更新流程内容变动后要同步重算对应向量索引置信度虚高模型对相似问题的置信阈值没有校准先人工标注100条测试集统计各个阈值下的准确率后选择合适阈值还有一个值得补充的排查点不要只看API返回的confidence字段就完全信任它。大模型本身并不擅长估计自己的确定性。在实际运作里知识库有无相关文档比模型说有多自信更可靠。我后来增加了规则如果检索结果小于两条即使模型返回高置信度也强制进人工池。5.2 测试与性能优化测试是很多人容易偷懒的环节。我建议准备一张测试集至少 100 条真实的工单历史数据手工标注好正确分类然后跑一遍分类接口把准确率统计出来。准确率达不到 85% 以上就先不要上线自动派单只能作为辅助字段展示给客服。如果准确率过了 90% 以上可以考虑开启自动派单但仍要保留人工调整入口。性能上我个人建议先关注三个指标才去谈优化模型单次响应耗时、向量库检索耗时、整条链路端到端耗时。单台普通服务器上embedding 检索通常只要几十毫秒主要耗时大头全在模型推理。除了换更大显存之外有两个更低成本的优化手段一是把常见问题及其标准答案做成预置缓存比如高频问题直接命中缓存就不用再调模型了二是对于一些固定场景直接写规则匹配优先拦截比如工单标题里包含发票就优先分类到财务命中不了规则再交给大模型。规则和大模型组合使用往往比单纯依赖大模型更省钱也更稳定。6. 影响范围与后续扩展6.1 这套方案能用到哪些场景别看标题挂着工单系统这套低代码 大模型的组合思路是可以迁移到很多相似场景的。我了解到的实际案例里有团队用同样方案做了 IT 内部运维入口员工提交网络连不上软件安装不了系统直接给操作手册让大部分问题在员工侧就消化了也有售前团队做了报价咨询入口先用知识库答复型号和价格复杂度高的需求再转人工。医疗预约、高校招生咨询、物业报修逻辑都是同一套结构化表单收集信息模型做意图理解低代码做流转分配。影响范围最明显的是响应速度。原来客服团队处理一条工单的平均时间是二三十分钟现在高频问题的即时回复率能做到 60% 以上剩下的人工工单因为已经有了分类和摘要处理时间也能压缩一半左右。成本上API 调用按量计费一个月几百次调用折算下来几乎可以忽略真正贵的是整理知识库和调优 Prompt 的人工时间但这是一次性投入。我另外一个很深的体感是这类项目不像传统软件项目需要一个很长的需求文档。用低代码你能先跑起来用一个月积累真实数据再逐步调整规则和知识库整个演进过程非常平滑。6.2 经验总结与后续扩展最后说说我自己的感受和后续打算。搭完这套系统我最大的体会是模型能力不是瓶颈工程配套才是。大模型本身的回答能力已经很能打难的是怎么把知识库维护好、让生成结果稳定落地到业务流程里、在模型出错时设计好兜底和补偿机制。这些问题靠的是一板一眼的工程功夫而不是换个更强的模型就自动解决。把知识库结构做好、Prompt 写严谨、超时和失败处理到位系统的可用度和专业度一下子就出来了。后续我准备做两个扩展。一个是工单处理完成后的自动知识沉淀客服在后台修改 AI 建议的那一刻就把修改前后的文本存下来攒够一定量后做一次增量微调或用它来增强知识库词条另一个是给用户侧加一个多轮问答界面基于历史上下文做连续对话不再限制于单条问题单次回复的模型。如果你现在正准备动手搭自己的智能工单系统我建议你先别急着买卡、配模型找一个周末把知识库整理好、用 API 跑通一条端到端链路再决定要不要本地部署。这条路我就是这么走通的。
以前给客户做运维平台的时候最让我头疼的不是系统崩溃是工单区每天被二三十条我密码忘了怎么办系统登不上去的重复提问刷屏。挨个回复吧浪费时间不回复吧用户满意度又往下掉。后来我干脆把工单系统和问答机器人打通用户提交问题的时候系统先自动识别意图、从知识库抓答案顺带把工单分类和紧急度都填好再决定是直接回复还是转人工。整个方案的核心就两个词低代码 大模型低代码管流程、页面和权限大模型管理解、分类和生成回复。这套思路让我用大约两周的业余时间搭完了一个能自动问答、自动分派、还能不断补充知识库的智能工单系统。这篇就完整拆解一下我是怎么从零搭出来的适合预算不多、又不想从零写表单和流程引擎的团队也适合想了解大模型怎么真正落到业务里的人。1. 方案设计与技术选型1.1 需求拆解智能工单系统至少需要哪些能力工单系统的本质不是记录一条反馈而是把问题在正确的时间送到正确的人手里。刚开始定制需求的时候很容易把功能想得特别大什么智能客服、自动处理、多轮对话全都加进来。我最后只保留了四个核心能力第一个是信息收集用户从网页表单、小程序或者企业微信提交问题系统要能用结构化字段记录标题、描述、联系方式、附件这些基础信息。第二个是自动分类与路由大模型读完问题后判断类型比如是账号问题、支付问题还是网络问题然后按规则分给对应负责人。第三个是知识库问答对于常见问题系统直接检索知识库生成答案并给出置信度如果足够高就原路回复。第四个是人工兜底所有拿不准的工单自动进人工池客服在后台能看到AI建议回复和分类依据。为什么需要这四件事因为只做自动问答而不做路由只是省掉了客服打字的时间只做路由而不做知识库问答又没有真正减少人工处理量。它们是配合起来才能起作用的。而且工单数据来源通常非常杂有客服电话转写的文字、有网页留言、有IM里的碎片消息大模型在这里的价值就是把非结构化文本清洗成结构化字段减少人来阅读的成本。1.2 为什么选择低代码 大模型而不是纯手写早期方案评审的时候团队里有人提议直接用 Spring Boot Vue 自己写一套认为这样可控性最高。这个想法本身没问题但我算了一笔账就没再犹豫一套带工单流转、角色权限、审批流、附件管理、消息通知的后台即使不用大模型纯手写至少要一到两个月而其中一半的代码是在重复做别人早就做好的事情。低代码平台把表单设计、流程编排、权限分配这些基础设施全都包了我只需要把精力放在智能这一层。大模型则补上了低代码做不了的部分。低代码平台擅长处理结构化数据和固定流程但不知道客户说登录时一直转圈到底是什么意思。而大模型擅长理解语义、抽取关键信息、生成回答但它不擅长做严谨的状态流转和数据关联。所以两者不是竞争关系是天然互补。我这次选型的原则就是一切有固定规则的功能尽量用低代码一切依赖语义理解的功能尽量用大模型边界非常清晰。还有一点需要提醒纯手写意味着后续每次加业务逻辑都要发版而低代码平台的规则修改往往改完立即生效。对于小团队来说这个灵活性比想象的更重要。1.3 平台与模型选型建议低代码平台这一步我对比了宜搭、简道云、明道云这几家常被提到的产品。考虑到后面要大模型接口回调重点看的是两个能力是否支持 HTTP 请求类型的集成自动化或自定义连接器以及普通表单/流程是否支持自定义按钮触发的服务端逻辑。平台表单与流程外部API调用适合场景宜搭完整和钉钉打通支持自定义连接器与集成自动化企业内部工具已有钉钉组织架构简道云完整操作上手快支持 API/Webhook 触发需要灵活接外部服务的团队明道云流程能力强支持自定义API和代码块复杂业务规则希望低代码内写逻辑大模型这边我分了两种路线。如果你只是验证想法直接用云端 API 就行主流大模型 API 的文本理解能力完全够用成本也不高。如果你有数据保密要求或者想长期压低调用成本就走本地部署方案用 Ollama 或 vLLM 跑开源模型。Embedding 模型我推荐 BGE-M3它综合能力在开源里属于第一梯队中文效果好而且支持稠密检索、稀疏检索、多向量三种方式后续做 RAG 召回时可以灵活适配。向量库小规模用 Chroma 足够规模大了换 Milvus。我这次实际用的组合是简道云做表单和审批流FastAPI 写问答服务通义千问 API 做文本理解BGE-M3 做向量化Chroma 做知识检索。2. 大模型与知识库接入细节2.1 模型调用方式的取舍API还是本地部署这一段是不少来问我的朋友卡得最久的地方。先说我自己的判断标准项目上线后每天调用量大概多少、响应时间要求多少、数据隐私边界在哪、团队有没有 GPU。如果每天调用量在几千次以下用 API 最划算省去运维成本而且模型能力天花板明显更高。如果系统要处理客户隐私数据或者调用频率高到每月 API 账单肉疼再考虑本地部署。本地部署到底需要什么配置很多人的误区是没有 A100 就别想跑大模型。实际上用量化后的 7B 模型推理占用的显存大概 56GB你 16GB 显存 32GB 内存的机器完全跑得动响应速度也基本够用。关键是选对量化精度Q4_K_M 在质量和资源占用之间最平衡。我测试过 32GB 内存的纯 CPU 机器也能跑但单次推理要几十秒只适合离线批量处理不适合在线工单问答。API 调用也要考虑一个隐藏问题默认超时时间。低代码平台调的 HTTP 节点一般只有 10 到 30 秒大模型在高峰期完全可能几秒才返回所以要么把超时时间调大要么用异步任务轮询结果。后面在联调部分我会细说处理方式。2.2 RAG让大模型真正懂你的业务直接把工单问题丢给裸模型它只能给你一个看起来正确但没啥用的通用回答因为模型没学过你公司的退款政策、产品报错代码和内部流程。让大模型真正懂业务的常用手段就是 RAG即检索增强生成。RAG 的基本流程是先把业务文档按语义切块比如每个段落控制在 200500 字太长了召回就不准然后对每块做 Embedding把向量存进向量库收到用户问题时再把问题向量化在库里做相似度检索取出最相关的几段最后把用户问题 检索到的业务片段一起拼进 Prompt 给大模型让它基于这些材料回答。这里有两个关键参数值得关注一是召回数量我一般 top_k 取 4 到 6 段太少回答缺乏上下文太多又容易引入噪音二是相似度阈值低于阈值的检索结果宁可不用。第一次搭建时踩过不少坑最典型的就是检索到一堆无关文档导致生成结果更差后来我统一用了标题正文拼接成一条向量再入库效果比单纯切正文要好得多。另外注意不是所有工单内容都适合进向量库。FAQ 类、政策类、操作手册类是首选涉及具体某个用户的个性化数据千万别往向量库里塞既有隐私风险检索价值也不大。2.3 智能问答的Prompt与上下文设计调用大模型最容易犯的错就是问一句帮我分类一下就完事了。实际生产环境里Prompt 就是你的程序代码写得越严谨返回结果越稳定。我给工单系统设计了三个核心任务意图分类、要素抽取、回答生成。分类任务的 Prompt 要点是明确给出所有候选分类以及每个分类的定义并要求只输出分类 ID。比如账号类包含密码找回、登录失败、账号锁定订单类包含未支付、退款、物流查询否则模型容易按自己的理解创造分类名称。要素抽取则要指定抽取哪些字段比如紧急程度、用户情绪、问题类型、涉及的业务模块并要求字段缺失时输出 null不要编造。我基本上都会要求模型返回严格 JSON并在 Prompt 里写明输出格式。同时为了保险程序里还要增加一层正则抽取逻辑万一模型夹带了多余说明文字也能把 JSON 主体扒出来这个防御手段在实际调用中非常重要。3. 低代码平台搭建工单主流程3.1 数据表设计与表单配置低代码平台里建表单是相对简单的但数据表设计决定了后续的智能流转是否顺畅。我的工单主表字段分成三组。第一组是用户填写的原始信息工单标题、问题描述、联系方式、附件第二组是智能引擎生成的字段问题分类、紧急程度、AI 建议回复、置信度、完整 JSON 记录。第三组是流程字段当前处理人、工单状态、处理结果、满意度评价。这里有个很重要的设计理念AI 生成的字段和用户提交字段分开存不要混在一起。一方面方便回溯另一方面避免大模型偶尔出错污染原始数据。完整 JSON 记录我用一个文本字段直接存原始返回万一后面要排查问题能直接看到模型当时到底返回了什么。表单交互上我用的是先提交后智能填充的思路。用户提交表单时只看到基础字段提交成功的同时触发集成自动化调用模型服务然后系统自动更新分类、紧急度这些智能字段。这样用户侧完全无感知客服后台看到的是已经结构化好的数据。3.2 工单流转与规则引擎配置工单流转我设置了四段状态待处理、处理中、已解决、已关闭。每条工单创建后默认是待处理但具体转到谁手里由大模型返回的分类和紧急度决定。低代码平台的流程节点里可以配置根据字段值选择处理人我需要在流程里写判断条件如果分类为账号类节点转给账号组如果分类为订单类转给订单组。为了提高自动化程度我还把紧急度映射成了处理时限高优先级要求 1 小时响应普通要求 8 小时超时自动推送一条提醒给负责人。这里想特别强调不是所有工单都适合完全自动派单。我在流程里加了一个分支节点当置信度低于 0.7 时工单不自动分配给具体负责人而是进入待人工分拣队列由客服主管手动拍板。这个兜底策略在实际运行中非常关键因为模型再强也会有判断错的时候保留一个出口比追求百搭更稳妥。3.3 低代码如何承接大模型返回低代码平台与大模型的接口对接是整体方案里最容易出问题的地方但也最不复杂。逻辑很简单在流程里配置一个 HTTP 节点请求方式选 POST请求体里面带上工单标题、描述等字段发到你的问答服务接口然后拿返回值里的字段去更新当前工单。在配置这种集成自动化时需要特别注意三点。第一是超时设置头部模型服务必须设置合理的超时上限网络波动时要能优雅降级不能因为模型服务不通就把整个提交流程卡死。第二是失败处理无论什么原因导致模型调用失败都不能让用户工单丢失。我用的方案是为容器专门配置了一个暂时的pending_status让工单先进入人工池同时留下标记方便事后重试比直接报错要优雅得多。第三是字段映射低代码平台里返回体通常是一个嵌套 JSON需要用点号路径把嵌套字段取出来先在小范围试跑一次确认能正确解析再发布比发布后反复试错成本低得多。4. 完整实战流程4.1 准备模型与知识库第一步永远是准备知识库不是写代码。我从客服团队要来了最近三个月高频提问记录整理成大约 180 条 FAQ按照账号、支付、订单、使用教程、其他五个分类归档成 CSV。每条记录包含标准问法、标准答案、关联业务部门。然后是文档切分和写入向量库。FAQ 内容不可能全篇塞给模型我按条目切分同时把分类信息合并进文本。接着用 BGE-M3 生成向量写入 Chroma。这个小规模的检索库我全部准备过程也就两小时但整个智能问答的效果全看这一步有没有做好。如果你手头有长文档一样的方式可以迁移到实际场景去处理。比如把产品说明书按 Markdown 标题分块每块再按语义截断配合一个小工具就能完成。我在实践中总结的原则是宁可每块短一点、数量多一点也不要用动辄上千字的长文本因为向量检索的精度会明显下降。4.2 搭建问答服务问答服务我用 FastAPI 写了两个接口。一个是/classify负责对工单做分类、紧急度判断、要素抽取一个是/query负责从知识库检索并生成回复。两接口都返回 JSON。核心示例代码如下我做了删减只留主干逻辑from fastapi import FastAPI from pydantic import BaseModel import requests import json import re app FastAPI() OLLAMA_BASE http://localhost:11434 MODEL qwen2.5:7b # 假设已预先把FAQ写入Chroma并持久化 from retrieval import search_faq class TicketIn(BaseModel): title: str description: str def llm_chat(messages: list) - str: payload { model: MODEL, messages: messages, stream: False, options: {temperature: 0.1} } r requests.post(f{OLLAMA_BASE}/api/chat, jsonpayload, timeout60) r.raise_for_status() return r.json()[message][content] def extract_json(text: str) - dict: # 用更加稳健的正则寻找 JSON 块 match re.search(r\{.*\}, text, re.S) if not match: raise ValueError(no json found) return json.loads(match.group()) app.post(/classify) def classify(ticket: TicketIn): prompt f 你是工单分类引擎只能输出JSON不能输出额外文字。 工单标题{ticket.title} 工单描述{ticket.description} 要求根据以下分类集合给出结果返回格式如下 {{ category: account|payment|order|guide|other, priority: high|medium|low, summary: 一句话概括问题, confidence: 0.0 }} raw llm_chat([ {role: system, content: 你是一个严格的分类器。}, {role: user, content: prompt} ]) return extract_json(raw) app.post(/query) def query(q: dict): question q.get(question, ) docs search_faq(question, top_k4) context \n\n.join([d[text] for d in docs]) prompt f 基于下面的知识库内容回答问题如果知识库中没有相关信息请明确说知识库中暂无此答案如需人工支持请提交工单。 知识库内容 {context} 用户问题{question} raw llm_chat([ {role: system, content: 你是企业知识库助手。}, {role: user, content: prompt} ]) return {answer: raw, source_docs: docs}服务起来之后我用 curl 做了简单验证curl -X POST http://localhost:8000/classify \ -H Content-Type: application/json \ -d {title:登录不上,description:我的密码改了之后一直登录不上一直显示账号锁定}返回结果类似{category: account, priority: high, summary: 用户修改密码后账号被锁定无法正常登录, confidence: 0.95}。这一步验证通过后面低代码就只是一个对接动作而已。4.3 联调从前端提交到自动分单全链路联调是整个项目里最能看到效果的环节。完整链路是这样的用户在表单页面填写工单并提交-低代码平台生成一条新工单记录-集成自动化自动调用/classify接口-模型返回分类、紧急度、置信度-低代码按规则更新工单字段并自动派单-客服后台看到已经分类好的工单和 AI 建议回复。整个过程在用户端没有任何感知他填完表松开手问题就已经在正确的队列里等候处理了。我第一次联调时发现一个实际体验问题用户点击提交到工单出现在后台中间会有三到八秒的等待时间原因是模型接口响应较慢。虽然不影响最终流程但用户体验一般。后来改成立即返回工单创建成功后台异步调用模型处理前端秒回智能填充在后台完成体验好了许多。低代码平台的发起流程和定时触发配合使用就能实现这种异步模式建议你在设计时就考虑进去。5. 常见问题与排查技巧5.1 常见报错与排查我把我实际遇到过的典型问题整理成一份速查表如果你也在搭可以直接对着排查现象原因解决方案低代码调用模型接口超时模型推理速度慢连接器超时时间太短将超时时间调到 30 秒以上更建议改为异步任务模式返回 JSON 偶尔解析失败模型在 JSON 外夹带注释或说明文字Prompt 强约束 正则提取 JSON 块 失败时走人工兜底向量召回结果与问题无关文本切块太长或信息混在不相关段落缩短切块长度标题内容拼接成单条向量排查阈值设置本地部署显存不足模型体积超过显存容量使用 Q4_K_M 量化或用 Ollama 自动部分卸载至CPU运行模型总是返回过时答案知识库更新未重新生成向量建立文档更新流程内容变动后要同步重算对应向量索引置信度虚高模型对相似问题的置信阈值没有校准先人工标注100条测试集统计各个阈值下的准确率后选择合适阈值还有一个值得补充的排查点不要只看API返回的confidence字段就完全信任它。大模型本身并不擅长估计自己的确定性。在实际运作里知识库有无相关文档比模型说有多自信更可靠。我后来增加了规则如果检索结果小于两条即使模型返回高置信度也强制进人工池。5.2 测试与性能优化测试是很多人容易偷懒的环节。我建议准备一张测试集至少 100 条真实的工单历史数据手工标注好正确分类然后跑一遍分类接口把准确率统计出来。准确率达不到 85% 以上就先不要上线自动派单只能作为辅助字段展示给客服。如果准确率过了 90% 以上可以考虑开启自动派单但仍要保留人工调整入口。性能上我个人建议先关注三个指标才去谈优化模型单次响应耗时、向量库检索耗时、整条链路端到端耗时。单台普通服务器上embedding 检索通常只要几十毫秒主要耗时大头全在模型推理。除了换更大显存之外有两个更低成本的优化手段一是把常见问题及其标准答案做成预置缓存比如高频问题直接命中缓存就不用再调模型了二是对于一些固定场景直接写规则匹配优先拦截比如工单标题里包含发票就优先分类到财务命中不了规则再交给大模型。规则和大模型组合使用往往比单纯依赖大模型更省钱也更稳定。6. 影响范围与后续扩展6.1 这套方案能用到哪些场景别看标题挂着工单系统这套低代码 大模型的组合思路是可以迁移到很多相似场景的。我了解到的实际案例里有团队用同样方案做了 IT 内部运维入口员工提交网络连不上软件安装不了系统直接给操作手册让大部分问题在员工侧就消化了也有售前团队做了报价咨询入口先用知识库答复型号和价格复杂度高的需求再转人工。医疗预约、高校招生咨询、物业报修逻辑都是同一套结构化表单收集信息模型做意图理解低代码做流转分配。影响范围最明显的是响应速度。原来客服团队处理一条工单的平均时间是二三十分钟现在高频问题的即时回复率能做到 60% 以上剩下的人工工单因为已经有了分类和摘要处理时间也能压缩一半左右。成本上API 调用按量计费一个月几百次调用折算下来几乎可以忽略真正贵的是整理知识库和调优 Prompt 的人工时间但这是一次性投入。我另外一个很深的体感是这类项目不像传统软件项目需要一个很长的需求文档。用低代码你能先跑起来用一个月积累真实数据再逐步调整规则和知识库整个演进过程非常平滑。6.2 经验总结与后续扩展最后说说我自己的感受和后续打算。搭完这套系统我最大的体会是模型能力不是瓶颈工程配套才是。大模型本身的回答能力已经很能打难的是怎么把知识库维护好、让生成结果稳定落地到业务流程里、在模型出错时设计好兜底和补偿机制。这些问题靠的是一板一眼的工程功夫而不是换个更强的模型就自动解决。把知识库结构做好、Prompt 写严谨、超时和失败处理到位系统的可用度和专业度一下子就出来了。后续我准备做两个扩展。一个是工单处理完成后的自动知识沉淀客服在后台修改 AI 建议的那一刻就把修改前后的文本存下来攒够一定量后做一次增量微调或用它来增强知识库词条另一个是给用户侧加一个多轮问答界面基于历史上下文做连续对话不再限制于单条问题单次回复的模型。如果你现在正准备动手搭自己的智能工单系统我建议你先别急着买卡、配模型找一个周末把知识库整理好、用 API 跑通一条端到端链路再决定要不要本地部署。这条路我就是这么走通的。
