物业知识为什么难以直接用于业主沟通？
在业主关系管理中，一次不准确的收费解释、一条已经失效的地方规定，或不同人员给出的相互冲突的答复，都可能放大争议并损耗业主信任。知识库首先要支持管家、客服、收费和管理人员基于同一事实沟通，而不只是让模型更快生成一段文字。
物业行业的资料并不少：法律法规、地方条例、部门规章、服务合同、操作规范、裁判案例和企业制度共同构成了一个庞大而分散的信息世界。真正困难的，也不是从中找到一段看起来相似的文字。
同一个“空置房物业费怎么收”的问题，在不同地区可能适用不同规则；同一份规定会经历修订、替代或失效；同一关键词下，还可能同时出现法律原则、地方细则、合同约定和个案观点。文本相似度无法自动回答它们的效力与适用顺序。
因此，我们给知识库设定的目标不是“搜得到”，而是三个更严格的结果：找得准、说得清、查得到原文。这也决定了我们不能从一个通用的文档问答框架出发，而要先构建物业领域自己的知识组织方式。
为什么我们不以传统 RAG 作为主架构？
传统 RAG（检索增强生成）的典型流程，是把文档切成片段并转换为可检索表示；问题到来时召回若干相似片段，再交给大模型临时生成答案。它适合快速接入一批文档，也擅长回答来源相对简单、上下文边界明确的问题。
但对物业知识而言，它优化的是“找相似内容”，不是“治理知识”。当答案需要同时处理地域、法源层级、版本时效、事项边界和多份资料之间的关系时，传统 RAG 有五个结构性问题：
- 切片会削弱文档结构。一条规定的定义、适用范围、例外条件和法律责任可能分布在不同位置。孤立片段即使语义相似，也可能缺少决定结论的上下文。
- 相似度不代表适用性。全国规则与地方规则、现行文件与历史文件都可能高度相似，但它们对具体问题的优先级完全不同。
- 复杂知识每次从头合成。一个跨多份资料的问题，需要系统在每次查询时重新找到、排序和拼接证据，回答容易随召回结果波动。
- 知识不会自然累积。一次查询中发现的概念关系、冲突或适用边界，默认不会变成下一次查询可直接利用的公共结构。
- 召回成功仍不等于可信。如果缺少来源治理和证据回拉，回答可能引用过期资料，或把模型生成的摘要误当成最终事实。
这不是说向量检索没有价值。它仍然可以成为同义表达发现、长尾资料搜索或非结构化内容探索的辅助能力。但在我们的架构里，检索技术不能代替知识分类、效力判断与来源治理，也不能独自决定最终答案。
如何从“检索文档”转向“编译知识”？
Andrej Karpathy 在 LLM Wiki 构想中指出，常见 RAG 系统会在每次提问时重新发现知识；另一条路线，是让大模型在新来源进入时，持续构建并维护位于用户与原始资料之间的结构化 Wiki。知识只需被认真整理一次，之后可以继续修订、交叉连接并不断积累。
上述内容是 Karpathy 提出的通用技术方向。LIGOWIN 借鉴了这个“持久、可累积的知识中间层”，并针对物业场景作出一个关键调整：Wiki 层负责组织与导航，原文层始终保有最终事实地位。模型生成的摘要可以帮助找到证据，却不能取代证据本身。
资料如何进入物业知识库？
每一份资料进入知识库，都要经历从“可读取”到“可判断”的转换。我们把模型放在擅长的语义理解位置，把确定性的格式、校验和写入交给稳定流程，避免让同一个生成步骤同时承担理解、存储和治理。
来源进入事实层
统一不同资料形态，保留标题、发布主体、地域、时效和法源层级等来源信息，让原文成为稳定、可定位的事实底座。
在全文理解上切分
法规按条文边界处理，研究与业务资料按完整语义处理。切分服务于证据定位，而不是把文档打散后再猜测上下文。
编译为领域知识
模型识别业务主题、核心结论、关键词、同义表达与适用条件，将新资料放入已有物业知识体系，并保留它与原文的连接。
挂载到分层索引
知识先进入领域目录，再按具体主题与地域展开。内容增长时只增加必要的下一层，而不是让所有问题面对同一份巨大索引。
完成治理闭环
入库同时检查重复、替代、失效、结构完整性与证据可达性；只有通过校验的更新才会进入可查询状态。
分层索引是这一步的核心产物。最上层只回答“问题属于哪个物业领域”；中间层回答“属于哪个业务主题”；当某个主题在不同地区积累了更多规则时，再进入对应地域的细分层。这样，知识库规模增长不会迫使每次查询读取更多无关内容。
与“先机械切碎、以后再找”的路线不同，我们强调全文理解在先、证据切分在后。索引中保存的是足以导航的知识摘要和适用边界，完整内容仍留在原始资料层。这减少了信息复制，也降低了摘要在多次转述中逐渐偏离原文的风险。
回答如何从索引回到原文证据？
查询路径遵循一个简单原则：Index First, Evidence Last。先用结构化知识缩小阅读范围，最后用原始证据决定回答。它既避免把全部资料塞进上下文，也避免只凭摘要下结论。
理解问题
识别用户真正询问的业务事项，以及问题中的地域、主体和时间条件。
索引路由
先从总目录选择少量相关领域，再进入具体主题与地域索引。
判断适用性
综合地域层级、法源效力、时效与事项匹配度筛选候选知识。
回拉原文
索引只负责导航；形成回答前必须读取对应的原文条款或完整证据段落。
补漏与交叉核验
用同义表达和精确文本检索补充索引可能遗漏的来源，并检查证据之间是否冲突。
组织答案
区分明确结论、适用前提与仍需核实的事实，同时给出用户能够理解的来源依据。
地域是物业查询中的第一类关键条件。系统会优先寻找与问题所在区县、市、省相匹配的资料，同时保留全国性规则作为上位依据。法源层级、发布时间和具体事项则共同影响候选证据的顺序。这个过程不是用一条简单的相似度分数能够替代的。
索引也不是绝对正确的。查询进入最后阶段时，系统会用关键词、同义表达和文本定位进行补漏。如果发现不同来源之间存在差异，回答不会强行合并为一句确定结论，而会说明各自的适用范围和仍需核实的事实。
知识编译的效率从哪里来？
LLM Wiki 路线把一部分成本从“每次查询”前移到“每次入库”。一份资料只需在进入系统时完成结构化理解，此后大量问题都可以复用同一套分类、关系和证据指针，而不必反复阅读整份文档。
全库召回 → 拼接片段 → 猜测关系 → 临时判断适用性 → 生成答案
理解问题 → 沿索引定位 → 判断适用顺序 → 回拉原文 → 形成答案
这种效率不只体现在响应速度，也体现在答案稳定性和系统维护成本上：
- 更小的上下文：每次只加载必要的索引和原文，减少无关信息干扰。
- 更稳定的路径：相似问题共享知识结构，不因一次召回排序变化而完全改写推理过程。
- 可增量更新：新资料只更新相关主题与关系，不需要重建整套问答逻辑。
- 可检查、可回退：知识结构和来源连接是显式资产，错误可以被定位和修正。
可信物业知识库的边界是什么？
LLM Wiki 并不会天然消除模型错误。知识编译本身可能遗漏信息，原始资料也可能过期或不完整。因此，我们把可信性拆成一组可执行的约束：不修改来源事实、不让摘要替代原文、不隐藏地域和时效边界、不在证据不足时给出过度确定的结论。
对法规、合同和争议处理等高风险问题，知识库提供的是信息检索、证据整理与决策辅助，不替代企业内部审批或专业法律意见。系统能够把“答案为什么这样说”呈现出来，最终判断仍应结合真实项目事实。
一致、可核验的信息有助于保护业主信任，但不会自动解决服务问题或费用争议。物业人员仍需核实现场事实、推动责任闭环并对沟通结果负责；知识库提供依据，不替代真实服务交付。
未来我们仍会吸收检索技术、知识图谱和评测体系中的有效方法。但主线不会改变：让每一份新资料都改善知识结构，让每一次回答都经得起回到原文重新检查。