1. 物业公司为什么非要做一套自己的大模型先说一个特别真实的画面。某区域物业公司的客服坐席接起电话业主说我家厨房下水返味上个月你们人来看过一次说是立管的事现在又返了你们到底管不管。坐席需要同时确认五件事这个业主属于哪个项目哪一栋、上次报修是什么时间什么结论、立管属于公共部分还是户内、这类问题走哪种工单类型和派给谁、以及公司对公共立管返味的处理口径是怎么写的。这些信息散落在工单系统、纸质维保单、项目微信群聊天记录、一份三年前的《共用设施设备维护手册》PDF、还有一位快退休的老师傅的脑子里。通用对话模型放到这个场景里,基本答不出有用的东西。它不知道立管在这家公司的口径里算不算公共部分,不知道这个项目的维保班组怎么排班,更不知道上次那张工单最后是怎么结的。你要它硬答,它就会编。这就是检索增强生成RAG要解决的问题:模型负责语言组织和推理,事实和口径由你自己那套资料来提供。用它来做一个物业行业大模型,本质上不是训一个模型出来,而是给通用模型装上一套可检索、可追溯、可权限管控的企业知识底座。这篇东西写给三类人看:一是物业公司里负责信息化、数字化那块的技术负责人,想知道这套东西大概要投多少人、多少时间、多少机器;二是刚接触 RAG 的开发者,想找一个业务边界清楚、数据不算太脏也不算太干净的落地场景练手;三是业务口的同事,想知道这东西到底能替人干什么活、不能干什么活。我下面讲的链路、参数、坑,都是按一个中型物业公司,十几个项目,几百号员工,历史文档几千份这个量级来写的,规模更大的按比例放大就行,逻辑不变。我先把结论摆出来:**在这个行业里,RAG 的成败有七成不在模型上,而在文档解析、切分和元数据设计上。**很多人一上来就纠结用哪个模型、向量维度选多少,其实那部分调参的空间远小于把一份扫描版维保手册正确拆成可用片段的空间。后面的章节会把这个判断拆开讲清楚。2. 先想清楚:为什么是 RAG,不是微调2.1 物业知识的三种脏形态做这个项目最先撞上的不是技术问题,是资料问题。我把见过的物业文档归了三类,每类的处理难度差一个量级。第一类是结构化但分散的数据。工单记录、设备台账、巡检打卡、收费明细,这些躺在业务系统里,字段规整,但跨系统对不上号。同一个设备,台账里叫1#楼消防水泵,工单里叫消防泵A,维保单上手写成消泵一。这类数据的价值极高,因为它是事实,不是说法,但要做检索就得先做实体对齐。第二类是半结构化的规范性文档。作业指导书、应急预案、维保手册、服务标准、外包合同。这类是 Word 和 PDF 为主,有标题层级,有表格,有流程图,是最适合 RAG 的原料。难点在于版本混乱——同一份《保洁作业标准》在三个项目上有三个改过的版本,哪个是现行有效,系统里没有标记。第三类是完全非结构化的经验。微信群里的处置对话、老师傅的口头经验、投诉处理时的沟通话术。这类信息密度最高、最贴近实战,但也最难治理:一句话脱离上下文就没意义,而且里面经常夹着不该外传的内容,比如某供应商的报价、某业主的个人信息。注意:第三类数据不要一上来就全量灌进去。我的做法是先只收经过业务负责人确认过的问答对,由人把群聊里的有效处置经验改写成标准问答,再入库。全量灌原始聊天记录,短期看召回率高,长期看是把噪声和风险一起搬进了系统。2.2 微调与 RAG 的取舍:我们为什么不选微调经常有人问,既然要做行业大模型,为什么不拿开源模型做微调?我的回答是:微调解决的是说话方式问题,RAG 解决的是事实来源问题,这个项目的主要矛盾是后者。微调有几个绕不过去的坎。一是知识更新,RAG 里改一个文档第二天就生效,微调要重新训、重新评、重新发版。二是溯源,坐席答错一句话,主管要问你依据哪份文件,RAG 能给出原文片段和出处,微调出来的模型给不出。三是幻觉,RAG 可以设计成没检索到就说不知道,微调模型倾向于把训练时见过的东西编出来。四是权限,同一个问题,项目经理能看的内容和外包保洁员能看的内容不一样,这个只能在检索层做过滤,微调模型做不到。所以我们的方案是主链路走 RAG,只在两个地方考虑轻量微调:一是意图分类和查询改写这类小任务,用几百条标注数据训一个分类器或者小模型,成本很低、效果比通用模型稳;二是输出风格,如果希望回答更贴近公司话术,用几百条高质量问答做 LoRA 微调,但它只是给最后一步润色,不承担知识供给。这里有个判断标准可以借给你用:**如果一个问题答错,你能指着一份文档说应该是这样,那就该用 RAG;如果一个问题答错,是因为语气、格式、术语习惯不对,那才考虑微调。**大部分物业场景属于前者。3. 整体架构拆解:一条链路分成五段3.1 五段式链路与各段的职责边界整套系统我拆成五段,每段有自己的输入输出和验收标准,分开做的好处是出了问题能定位到段。第一段文档解析:把 PDF、Word、Excel、扫描件、图片统一转成带结构的文本。验收标准是人眼看不出来信息丢失。第二段切分与增强:把长文本切成适合检索的片段,并给每片挂上元数据(项目、文档类型、生效日期、密级、设备类别)。验收标准是任意一个业务问题,理想片段能落在某个 chunk 里。第三段索引:文本向量化 关键词索引双写。验收标准是给定一条查询,5 秒内返回候选集。第四段检索与重排:混合召回、融合、重排、截断。验收标准是Recall5 达到设定阈值。第五段生成与输出:拼 Prompt、调模型、结构化输出、引用标注、拒答判定。验收标准是答案有据可查,无据可拒。这五段里,前两段花的时间通常占总工期的一半以上,但很多人做 demo 时直接用一份干净的 Markdown 就跳过去了,上线才发现真实文档根本不长那样。3.2 选型清单与理由下面这张表是我们最终定下来的组合,附上为什么这么选。环节选型选择理由什么情况下该换文档解析开源解析库 OCR 服务 少量人工校对大部分 Word/文本型 PDF 能自动处理,扫描件靠 OCR 兜底,关键文档人工过一遍扫描件占比超过三成,考虑加表格识别专用模型切分按标题层级切 定长兜底规范性文档天然有层级,顺着切语义完整纯问答型知识库,改用问答对切分向量模型中文语义向量模型(千维左右)中文语义检索效果好,部署成本可控有大量专业缩写,考虑领域内继续训练关键词检索倒排索引(如 Elasticsearch)设备编号、房号、故障码这类精确串,向量检索很吃亏数据量小可以直接内存 BM25向量库开源向量数据库(如 Milvus、Qdrant)支持标量过滤,权限隔离好做数据量小可用轻量方案先跑重排模型轻量交叉编码器把召回的前 20 条精排到 5 条,准确率提升明显延迟敏感场景可只靠融合排序生成模型通用大模型(API 或私有化)语言组织能力强,配合严格 Prompt数据不出内网,换私有化部署方案4. 知识入库:七成败在这里4.1 文档解析的四个真实坑第一个坑是页眉页脚和目录污染。一份 120 页的手册,每页页眉印着XX公司 第X版 内部资料,如果不做清洗,这些字符串会出现在每一个 chunk 里,向量检索时它们会拉高片段之间的相似度,把无关内容顶上来。处理办法是在解析阶段按行频统计,把在超过 70% 页面重复出现的短行直接删掉。第二个坑是表格被拍平成文字。物业文档里表格极多:维保周期表、巡检项清单、责任分区表。PDF 抽出来经常变成水泵 每月 轴承润滑 500小时这种串行的词,语义全丢了。我们的做法是识别到表格后转成 Markdown 表格再入库,并且表格整体作为一个 chunk,不切开。一张 10 行的表切两半,任何一半都没法用。第三个坑是扫描件的 OCR 错字。设备编号DL-203被识别成DL-2O3(字母O和数字0),这类错误在关键词检索里是致命的。对策是建一个业务词典,把设备编号、楼栋编号、故障码这些做正则后处理和纠正,同时在元数据里保留原始编号的多个写法,查询时做同义扩展。第四个坑是多栏排版。有些项目自己做的服务手册是双栏排版,PDF 抽取会按行读,左边一栏和右边一栏的文字交织在一起,读出来是乱码。这类文档量不大,我建议直接人工重排或者单独处理,不要在通用解析上浪费太多时间。我的经验:**先拿 20 份最有代表性的文档做人工解析对照,把解析后文本和原文逐段比一遍,记录丢失和错乱的比例。**如果某类文档的丢失率超过 10%,就不要进库,先解决解析。垃圾进垃圾出,这一步省下来的时间后面会以十倍还回去。4.2 切分策略与参数怎么定切分这件事没有万能参数,但有推导方法。我给一套可复现的流程。**第一步,按标题层级做语义切分。**一级标题下的内容如果不超过 600 字,就整块保留;超过就往下切到二级标题;二级标题下的内容还超过,再按段落切。这样切出来的片段,天然带着这份材料在讲什么的上下文。**第二步,定 chunk 长度。**中文场景我用的是 300 到 500 字,overlap 取 15%,也就是 50 到 80 字。为什么是这个量级?两个约束:一是向量模型的输入长度有限,超长会截断,语义被稀释;二是生成阶段要塞 5 条片段进上下文,如果每条 1000 字,光上下文就两三千字,成本和延迟都上去了。你可以在 200、400、800 三档上各跑一遍离线评测,看 Recall5 的差异,一般 400 左右是个拐点。**第三步,算一下存储,心里有个数。**一本 120 页的维保手册大概 6 万字,按 400 字一块、15% 重叠,实际每块覆盖约 340 字新内容,大约切成 180 块。用 1024 维的向量,单精度 4 字节,一块占 4KB,180 块不到 1MB。就算你有 3000 份文档、平均 5 万字,总共 3.7 亿字,切出约 110 万块,向量存储约 4.4GB。这个量级对向量库来说毫无压力,真正吃资源的是生成阶段的 token 消耗,不是向量存储,这一点很多人在做预算时会估反。**第四步,给每块挂元数据。**这一步是分水岭。我们挂的字段包括:项目编号、文档类别(制度/手册/合同/问答)、设备类别、生效日期、版本号、密级、原文位置(页码段落序号)。有了这些,检索时可以先用标量过滤缩小范围,再做向量匹配,准确率提升非常明显。举个具体的例子。业主问消防泵多久试运行一次。如果不带元数据过滤,向量检索可能召回一份三年前的旧版手册、一份针对商业项目的标准、还有一份住宅项目的标准,三个答案可能不一样。加了项目类型住宅和生效状态现行两个过滤条件,候选集立刻干净了。同一份文档的不同版本,在入库时一定要打上版本和生效状态,旧版本标记为归档而不是删除,因为有些历史工单的处置依据就是旧版,处置追查时需要能查到。4.3 元数据设计清单字段类型用途是否必填项目编号枚举数据隔离,检索过滤必填文档类别枚举不同类别走不同切分策略必填设备/业务域枚举缩小检索范围选填版本号字符串追溯与展示必填生效状态枚举(现行/归档)默认只检索现行必填密级枚举权限过滤必填原文位置字符串引用展示必填更新日期日期时效性排序加权必填5. 检索层:从能搜到到搜得准5.1 混合检索:关键词与向量的分工纯向量检索在物业场景有个明显短板:**设备编号、房号、故障码这类精确串,向量化之后语义会糊掉。**业主说3 栋 2 单元,向量检索可能给你召回2 栋 3 单元的维保记录,因为它们语义空间里挨得近。而关键词检索对这类串是精确命中。所以主链路必须是混合检索:关键词召回一批,向量召回一批,然后融合。融合我推荐用倒数排名融合(RRF),它不依赖两路分数的量纲,鲁棒性好。下面这段是核心逻辑的骨架,可以直接改改就用。def rrf_fuse(keyword_rank, vector_rank, k60, w_kw1.0, w_vec1.0, top_n20): 两路召回结果按倒数排名融合 keyword_rank / vector_rank: [(chunk_id, score), ...] 已按分数降序 scores {} for rank, (cid, _) in enumerate(keyword_rank): scores[cid] scores.get(cid, 0.0) w_kw / (k rank 1) for rank, (cid, _) in enumerate(vector_rank): scores[cid] scores.get(cid, 0.0) w_vec / (k rank 1) return sorted(scores.items(), keylambda x: x[1], reverseTrue)[:top_n]k取 60 是文献里的常用值,作用是压平头部差异,避免某一路的第一名直接锁死结果。权重w_kw和w_vec我一开始设成 1:1,实测发现业务问题里怎么回事怎么办这类语义型问题占七成,所以把向量权重调到 1.3、关键词 0.7,整体命中率提升了一截。这个比例没有普适值,得看你自己的问题分布。5.2 重排与 TopK 的实测数据融合之后拿到 20 条候选,再送进重排模型精排,取前 5 条进上下文。下面是我们在 300 条评测集上的对比,能说明为什么要加这一层。方案Recall5Recall10单次检索耗时纯向量,top5 直接进上下文61%72%180ms纯关键词48%63%60ms混合 RRF,top574%85%240ms混合 RRF 重排,top586%89%620ms从 61% 到 86%,这 25 个百分点的提升几乎全来自混合 重排这两步,模型一行没动。延迟从 180ms 涨到 620ms,对坐席辅助这种场景完全可以接受,因为人读答案也要几秒。如果是嵌入到工单系统里做自动分类,对延迟敏感,那就退化成混合 RRF 不加重排。有个细节值得单独说:**重排之后不要机械取前 5。**我们的做法是设一个分数阈值,重排分数低于阈值的直接丢掉,哪怕只剩 2 条。宁可少给模型两条可靠依据,也不要凑数塞三条噪声进去,后者会显著提高编造概率。5.3 查询改写:把口语翻成书面语业主的原话和文档里的表述差得很远。我家厨房下水返味对应文档里的排水立管异味返溢;电梯老晃对应轿厢运行抖动;楼道灯不亮对应公共区域照明故障。不做改写,向量检索的相似度会被口语噪声拉低。查询改写有三种做法,按成本从低到高:一是同义词词典,把常见口语表达映射到标准术语,维护几百条就能覆盖大部分高频问题,这是性价比最高的;二是小模型改写,用几百条口语-书面配对训练一个改写模型,延迟低;三是用生成模型做改写,效果最好但每次查询多一次调用,成本翻倍。我们的组合是:词典先过一遍,词典没命中的再走小模型改写,生成模型改写只在离线评测里用来造数据。这里有个容易忽略的点:**改写要保留原查询一起做检索,而不是替换。**业主说3 栋下水返味,改写后是排水立管异味返溢,但3 栋这个关键信息不能丢。我的做法是两条查询分别检索,结果合并去重,再一起融合排序。6. 生成层:让它说人话,更要说实话6.1 系统提示词的结构生成层是整个链路里最容易被低估的一环。同一批检索结果,提示词写得好和写得差,答案质量能差出一个档。我们的提示词分成五块:角色与边界、上下文注入、引用规则、输出格式、拒答策略。你是某物业公司的内部知识助手,服务对象是一线客服和项目管理人员。 【回答规则】 1. 只能依据下面提供的【参考资料】作答,不得引入资料之外的信息。 2. 每条结论后面用 [编号] 标注依据来源,例如 [1][3]。 3. 如果参考资料不足以回答,直接回复资料中未收录该问题的处理口径,建议联系XX岗位确认,不要推测。 4. 涉及金额、责任划分、时间承诺的问题,只陈述资料原文,不做延伸解释。 5. 回答控制在 300 字以内,先给结论,再给依据要点。 【参考资料】 [1] (来源:住宅项目共用设施维保手册 v3.2 第14页) ... [2] (来源:客服处置口径问答 第7条) ...这几条规则里,第 3 条和第 4 条最关键。第 3 条把不知道变成一个合法输出,而不是失败,这一条能把幻觉率压下去一大截。第 4 条是因为物业场景里金额和责任划分太敏感,模型多做一步推理就可能给出错误承诺,不如直接约束它只做原文陈述。6.2 拒答阈值怎么定拒答不能只靠提示词,还得有数值判断。我们在检索后加了一道闸:重排最高分低于阈值 T 时,不进入生成,直接返回兜底话术。T 怎么定?拿评测集跑一遍,画出最高重排分-答案是否正确的分布,找一个能挡住大部分错误答案又不误杀正确答案的点。我们最后定在 0.35 左右,在这个点上,该拒的拒掉了约八成,误拒不到一成。同时还要处理另一种情况:**检索到了,但内容是旧版或者不相关。**这个靠元数据过滤解决,不靠分数。前面说的默认只检索现行版本就是这个作用。6.3 结构化输出:让答案能直接进业务系统坐席辅助场景里,答案只是给人看的。但如果是嵌到工单系统里自动填单,输出就必须是结构化的。我们让模型输出 JSON,字段包括工单类型、紧急程度、建议派单班组、处置要点、依据引用。这里要注意,JSON 输出一定要做校验和兜底解析,模型偶尔会多输出一段解释性文字导致解析失败。做法是用支持结构化输出的接口能力,失败时降级为正则提取关键字段,再失败就走人工。7. 三个已经跑起来的场景7.1 客服坐席实时辅助这是投入产出最直接的一个。坐席接电话时,系统把通话实时转写,提取关键词做检索,在坐席界面右侧推送三条依据片段和一段建议话术。坐席采纳与否都会记录,采纳率是我们最看重的指标之一。上线初期采纳率只有 40% 出头,原因不是答案错,而是推得太慢。转写有延迟,检索有延迟,等答案出来坐席已经自己说完。后来做了两件事:一是把检索改成流式的,不用等整句转写完,关键词一出来就先召回;二是把高频问题的答案做本地缓存,命中缓存直接出。采纳率提到 68%。这个场景还有个隐性收益:系统记录了大量问题-检索结果-坐席实际回答的三元组,这些数据是后续做评测集和微调的最好素材,比人工造题真实得多。7.2 设备维保问答与巡检指引设备维保的知识密度最高,也最适合 RAG,因为答案几乎全是某型号设备某周期做某事这种可查证的事实。我们把设备台账和维保手册做了实体对齐,提问时带上设备编号,检索时用编号做元数据过滤,准确率一下就上来了。巡检场景是另一个用法:巡检员在手机上问今天去 2 号配电房要查哪些项,系统按设备类别检索巡检清单,输出成勾选列表。这里的重点是输出要能离线缓存,因为配电房、地下室、水泵房这些位置信号往往不好。我们做的是每天凌晨把当天巡检计划涉及的清单预生成好下发到手机端,现场不需要联网。7.3 新人培训与 SOP 问答物业行业人员流动快,新人培训成本高。我们把新人最常问的问题(怎么开单、怎么升级投诉、什么情况要上报、报销流程怎么走)做成了一个问答入口,新人直接问,系统给答案并附原文出处,让他自己去看完整制度。这个场景有个额外好处:**它会暴露文档本身的问题。**系统上线第一个月,后台收到最多的反馈是这条制度的两个版本说法不一致。顺着这些反馈,业务部门清理了一批过期文件,这件事的价值可能比模型本身还大。8. 评测、上线与持续运维8.1 评测集怎么造才不虚评测集不能靠技术团队自己编题,那样只能测出模型的语文水平。我们的做法是从历史工单里挖:抽取近一年的工单,按业务类型分层抽样 300 条,由业务骨干把业主原话 标准答案 依据文档位置补齐。这个过程花了两周,但它是后面所有调参的地基。评测维度我列了四个,每个都有明确的判定标准。指标定义判定方式目标值检索命中率标准依据片段是否在召回的前 5 条内程序自动比对≥85%答案正确率答案要点是否覆盖标准答案关键点人工抽检 自动要点匹配≥80%引用准确率标注的引用是否真的支撑该结论人工抽检≥90%合理拒答率无依据问题中正确拒答的比例专门构造的对抗集≥75%第四个指标要特别注意。要专门构造一批看起来像公司制度其实文档里没有的问题,比如问一个不存在的设备型号的维保周期,看系统会不会编。这类对抗集是检验幻觉的最有效手段。8.2 灰度发布与反馈闭环上线不要一次全量。我们的节奏是:先是技术团队内部用两周,再选一个项目试点一个月,再扩到三个项目,最后全量。每个阶段看三个数:日活使用人数、答案采纳率、负反馈率。如果负反馈率超过 10%,停下来查原因,不要往下扩。反馈闭环的设计很简单但要真跑起来:每条答案下面有点踩按钮,点踩后弹出原因选项(答案错误/引用无关/内容过期/答非所问)。这些数据每周汇总一次,分成两类处理:内容问题交给业务部门修文档,检索问题交给技术团队调参数。没有这个闭环,系统上线三个月就会慢慢烂掉,因为文档在变、业务在变,而索引不会自己更新。8.3 增量更新怎么做文档更新是常态。我们做的是事件驱动:文档管理系统里有文件新增或修改,触发解析、切分、向量化,新片段入库,旧片段标为归档。这里有个坑要提前防:更新过程中如果解析失败,不能把旧数据删掉,否则会出现文档更新完,知识反而没了的事故。所以流程一定是先写新、再验证、最后归档旧。9. 踩过的坑与成本账9.1 常见问题速查表现象大概率原因排查动作答案答非所问查询改写没生效或改写过度打印改写前后查询,对比召回结果相同问题答案每次不一样上下文塞了过多相近片段降低 topK,提高重排阈值明明有文档却说没有元数据过滤过严或密级设错关闭过滤重跑,定位是哪个字段挡的编号、房号总是错纯向量检索,缺关键词路检查关键词索引是否命中,补同义词回答太长抓不住重点提示词没约束长度和结构加字数限制和先结论后依据规则旧版口径被引用归档标记没打或过滤没开查元数据生效状态字段首字延迟超过 5 秒检索链路串行、缓存未命中拆解各段耗时,加高频缓存9.2 成本估算:钱花在哪按前面说的中型规模算一笔账。文档约 3000 份,切出约 100 万片段。向量存储几个 GB,一台中等配置的机器或云上一个小规格实例就够,这部分成本可以忽略。真正的大头是生成调用。一次问答的 token 消耗大概是:系统提示词 600,五条片段共 2500 字约 3500 token,用户问题 50,输出 300,合计约 4500 token。如果每天 2000 次问答,就是 900 万 token。按常见的按量计费区间估算,这是一笔每月四位数的开销,不算离谱,但要注意两件事:一是把检索做准能显著降本,因为你可以少塞片段;二是高频问题加缓存,我们实测缓存命中率能到 35% 左右,直接省掉三分之一的调用。人力上,一个懂业务的兼职对接人(负责文档整理和评测标注) 一个后端 半个前端,三个月能出一个可用的版本。这个估算的前提是文档相对规整,如果扫描件占比很高,解析那块的工期要单独加。9.3 几条不上文档的经验第一条,**先做窄,再做宽。**我们第一版只做了一个项目、一个业务域(设备维保),把链路跑通、指标做上去,再横向扩。反过来做,一上来就全公司全业务,最后每个场景都不好用,团队也失去信心。第二条,**业务部门的参与度决定上限。**技术团队能解决解析和检索,但这个答案对不对这个口径是不是现行只有业务能判断。评测集那 300 条,业务骨干花了两周做,这两周是整个项目里回报最高的投入。第三条,**别追求 100% 准确。**这类系统本质是辅助工具,坐席看到三条依据自己判断,比看到一条绝对正确的答案更有安全感。我们的目标从来不是替代人,是把翻三份文件找一句话的时间从五分钟压到五秒。第四条,**权限一定要做在检索层,不能做在展示层。**有些团队的做法是先检索出来,前端再根据角色隐藏。这是不行的,内容已经进了模型上下文,模型完全可能在答案里说出来。正确做法是在向量库查询时就带上标量过滤条件,让不该看的内容压根不出库。这套东西上线到现在,我个人最大的体会是:**RAG 这个技术本身不难,难的是把一个行业的隐性知识显性化。**文档清洗、版本治理、口径统一,这些活一点都不酷,但做完之后你会发现,检索准确率的提升幅度远超你调任何模型参数能带来的。如果这套链路要往下扩,我建议下一步不是换更强的模型,而是把工单系统的结构化数据接进来做成结构化检索一路,和文本检索一起融合——设备台账、历史工单这类数据一旦能参与召回,很多这个设备以前出过什么问题的提问才算真正答得上来。