WHAT · 能做什么 · 某院真实案例 · 以数据说话

一条把门关好，一条把活干完。

不是两个产品，是同一台机器上的两条流水线。每条能力后面都跟一句「真实数据」——数字不是形容词，是日志里的字段。

前四类跑在该单位内网；第五类（情报）跑在 JAVIS 自己的业务里，不在客户机房——列在这里是为了交代「这套东西我们自己也在用」，不计入客户业绩。

8 个数字，全部来自本机日志。

取数区间 2026-08-22 — 10-24；来源为审计日志、业务库与向量库。不是抽样，不是估算，不是「按经验折算」。

运维：70 次每日备份成功（131 GB）· 13,449 次健康检查、189 次自动重启 · AI 相关数据约 57 GB。单机：27B 模型、218K 上下文、31.9 GB 显存 100% GPU，全程离线。

另有 37 道业务真题的 POC 验收：有效作答 37/37、应拒答 4/4 全部拒答。同一套系统也跑着 JAVIS 自己：77 篇行业动态、15,343 条线索、24 套成片。

下文按知识库、问答、录像评议、转写与文书、单机极限、运维六节给出逐项明细与复核方式。文中「篇」指文档数，不是页数；「片段」是检索命中的最小单位。

4,408 篇不是「导入」出来的，是一遍遍过闸留下的。

入库采用「整库增量扫描 + sha256 幂等」：每次遍历全部源文件，内容没变就跳过，变了就废止旧版、写入新版。所以「累计入库」和「现有存量」不是一回事，混着说就会重复计数。

书籍文献只占有效文档的 5%，却贡献了 77.8% 的有效语料——问答能不能「说到点子上」，主要靠这一块；裁判文书与案例库合计约 2,000 篇（件），负责实务口径。

两条口径：① 文档 ≠ 片段，一篇按 300–800 字切成平均 39.8 片；② 累计入库 ≠ 现有存量，旧版废止后不计入。另有 778 条 doc_failed 事件（多为扫描件无文本层），与上表 1,155 篇次失败属不同计数口径：前者按事件计、后者按每次运行的失败累计；OCR 回补在做。

262 次问答：答案要能指回文件，指不回就拒答。

端到端时延包含向量检索、BM25、RRF 融合、4 条来源扩块、218K 上下文生成与完整性校验——所以「这次怎么这么快」的答案通常不是模型快，是缓存命中了。

时延的瓶颈在「提示处理」而不是「生成」：这台机器提示处理中位 149.5 token/s、生成中位 41.7 token/s；218K 上下文下缓存失效要全量重算 5.8 万 token 提示（约 6.5 分钟），命中则秒级返回。系统用「常驻模型 + KV 缓存 + 会话复用」把典型时延压到 24.5 秒。

36 场：AI 出初评，人定稿。

抽音轨 → 转写 → 说话人分离 → 文本清洗 → 大模型分项评分。每条扣分必须引用文字稿原话与时间戳，评委按时间点回听即可核对。

同一录像评 4 次：10-11 得 81.4 分，10-12 连续三次得 76.4、75.9、76.4 分——后三次同流程同文字稿，极差仅 0.5 分。首评与后续差约 5 分，来自流程参数与转写文本的前后变化，不是模型随机性。由此得两条使用要求：同一批次评议固定流程参数，否则分数不能横向比；先校稿、后评分，转写错字会直接压低 C、D 类得分。

36 场中 11 场为测试/验证/回归样本。剔除后 25 场非测试评议：平均 73.6 分、中位 76.0、合格及以上 17 场（68.0%），等级为良好 5、合格 12、基本合格 7、不合格 1——这组更接近真实办案录像上的水平。失分集中在 C（提问质量）与 E（沟通节奏），与人工评查经验一致。

读不完的交给转写，读不动的交给 OCR。

这一节最不像「宣传」：转写走的是 CPU、约两倍速；文档辅助一年只调用十几次。都是些不好看但真实的数字。

GPU 转写路径在本机受驱动与库版本限制暂不可用，所以这里写的是 2 倍速而不是 19 倍速。同一份报告里写了这条，页面上也不藏。

调用量小，是因为这几项本来就不是天天用的活；真正扛量的是问答、评议和每日入库。文书类功能的价值在「单次处理得完整」，不在次数。

27B、218K、31.9 GB：一台机器跑满，全程离线。

这些数字解释了一个常见疑问：同样问一句话，为什么有时 5 秒、有时 100 秒。

MTP 投机解码：累计生成草稿 26,965 个、接受 19,017 个，首位接受率 70.5%（位置 0/1/2 分别为 70.5% / 50.8% / 38.8%），平均接受长度 2.60 token/步。这是不换硬件提升生成速度的主要手段，但要扣掉草稿验证开销，不能按 2.6 倍理解。稳态显存结构（主模型约 18 GB + 嵌入模型约 3.5 GB）决定这台机器不宜同时跑第二个 27B 级模型——「跑重活前先卸载模型」的运维惯例就是这么来的。

有班次、有日志、有交接，才敢让它天天跑。

AI 项目最常见的死法不是模型不行，是上线三个月没人管。这台机器上的每个岗位都有触发时间、失败处置和留痕。

统计期内与 AI 直接相关的故障 6 类，全部在日志里留痕并处置，未造成数据丢失。故障表放在资料页而不是藏在附录里，是因为「出过什么事、怎么修的」比「从没出过事」更可信。

先 POC，效果立现。

不先买大平台：先用小范围 POC 验证，看到结果再决定投入。政企按框架或采购程序走。

效果四件事 · 写进 POC 验收

本页所有数字都可以当场复核：抽 20 个业务问题、抽 1 场真实录像、拔一次网线、做一次恢复演练。节省工时 =（原单件人工工时 − 复核工时）× 月处理量——别把「机器跑了 10 分钟」直接说成「省下 3 小时」。