智能审核
把材料与规范同时交给知识库，让模型先做一致性检查与初步判断，人工只处理边界情况。
场景一 · 对客户
智能客服
客服场景的老问题不是没有答案，而是答案散在手册、工单和几个老员工脑子里。
常见困境
- 服务时长受限：非工作时间没人接
- 人力成本高：重复问题占掉大部分工时
- 质量参差不齐：不同人给不同答案
- 知识难沉淀：处理过的经验留不下来
MossKB 的做法
- 把产品手册、FAQ、历史工单与话术导入知识库，扫描件走 OCR
- 用公开访问链接或浮窗脚本挂到官网、公众号与办公系统里
- 回答带引用片段，客服主管可以核对依据
- 按访客限制每日提问次数，避免公开入口被刷
场景二 · 对内部
智慧办公助手
制度、流程、规范、技术文档和培训材料，通常散落在共享盘、群文件和几个人的收藏夹里。
常见困境
- 新人上手慢，同一批问题反复问老同事
- 文档有多个版本，不确定哪份是现行有效
- 跨部门资料不该互相可见
- 答案没有出处，不敢直接照着办
MossKB 的做法
- 按部门建知识库，账号之间资源隔离，各看各的
- 多轮追问保留上下文，一次会话里逐步问清
- 历史超过 token 预算才压缩，长会话不悄悄丢信息
- 每个回答都能点开引用文档，需要时回到原文核对
场景三 · 对系统
业务系统 + AI
不一定要做一个聊天窗口。把知识库当作一个可调用的能力，嵌进原有的业务流程里，往往收益更直接。
智能决策
业务系统在关键节点调用接口，取回带出处的依据与结论，作为流程继续往下走的输入。
能力扩展
函数库提供内置模板，需要写代码的场景由隔离执行器运行，用户代码不会以 Java 进程的身份执行。
接入方式
- 浮窗脚本：一行 script 引入，不改造原有页面结构
- iframe：整页或局部嵌入，适合办公系统与移动端容器页
- 开放 API：业务系统直接调用，按应用维度授权
- 公开访问链接：生成带令牌的分享页，可随时重置
落地时注意
- 先确认语料质量：培训 PPT 与过期的通知混在一起，答案一定不稳
- 先划清权限：能问什么、谁能问，在建模之前定好
- 先定验收问题集：准备 30 条真实问题，改动前后都跑一遍
- 再谈体验：把答案格式、引用展示、追问引导逐步调顺
行业覆盖
同一套引擎，不同的语料
知识库不挑行业，挑的是语料是否真实、权限是否清晰。
政府
政策解读、办事指南与预约服务，群众提问先被知识库接住。
教育
教务咨询、校园服务与学术资源检索，减少重复答疑。
医疗
科室知识库辅助检索疾病信息与诊疗要点，缩短查资料时间。
制造
工艺文件、设备手册与安全规范问答，一线人员随手可查。
交通
运营规则、票务与出行服务咨询。
零售
导购知识库、门店素材与库存查询的统一入口。
能源
运行规程与应急预案检索，关键时刻少翻手册。
科技
产品文档、接口说明与售前资料的对外统一口径。
选型建议
什么时候适合用 MossKB
把它用在合适的地方，比把它说成万能更有价值。
适合
- 有大量内部文档，且要求数据留在自己机房
- 团队已有 Java 与 PostgreSQL 的运维能力
- 需要把问答嵌进现有系统，而不是再造一个入口
- 答案必须可追溯：能点开引用文档核对
- 希望先小范围验证，再逐步扩大语料与用户
不建议
- 只想接一个大模型 API 做通用聊天，不需要私有语料
- 要求开箱即用的完整工作流编排——这部分尚未全部实现
- 不接受 PostgreSQL 与容器化运维，也不想有人维护服务器
- 语料本身尚未整理，也不打算整理