纯文档型知识库，假如保密性没那么强，可以用大模型提实体，但最好不要完全无约束。

> 请教下，图谱这一块，实体是如何提取的呢，直接让大模型去阅读现有的文档，然后大模型自己提取吗 不太建议一上来就完全让大模型自由提实体，因为大模型实际也不好完全理解我们业务需要，能规则化抽取的，优先规则化；规则覆盖不了的，再用大模型补，可以试着用大模型写个结构抽取工具，然后再写一个前端可以去查看抽取的结果如何，后续可以加一些搜索啊展开啊查看啊等等功能，最终可以加入编辑功能就更完美了。

> 所有知识图谱的搭建都面临一个问题，就是知识本身是有时效性的。一旦过了这个时效，或者被别的文档进行覆盖时，旧的文档只配用来做归档，大概率不应该放入到回答当中去。 > > 所以就要搞自定义的路由，但这个路由的话，介入的节点也应该是在数据录入的时候。数据一旦录入，就可以判定现有的哪些文档是低价值并需要干掉的。 > > 目前看开源的 RAG 方案，好像都没有考虑这个问题。 确实，RAG 绝对不是越多知

> 我很好奇知识图谱RAG的效果，好像没有看到大规模落地的应用 大部分都是卖课的项目 ^-^ 我们现在也不是把图谱当万能解法，而是把它当结构化上下文来源。先用路由判断用户意图，再用图谱定位相关对象和上下游，最后再结合向量知识以及相关规则补说明，大规模落地应该不至于，因为大家做这个一般都是自用的，而且很多脱离自己的项目业务基本真的没啥用

> 是否可以把文档先用 AI 处理成合适的问答形式作为对应文档的摘要方便检索？ 可行，但是处理出来的依旧需要审核，同时关键业务我觉得依旧需要开发人员校准，最重要的就是某些文档它不适合给ai，主要是内部项目嘛，被逮着了可就不好了，慎重选择。

只部署了qwen，我们这个事比较初级的，大部分流程理解比较固定，我觉得完全可以固化一些prompt，实际上来说我们prompt、路由、RAG 知识、项目识别、底层规则基本全固化了，假如我们能用v4 flash，我觉得它不会呆成这样让我限制这么多，说多了都是泪啊其实我们干这个，就是因为模型本身不强，不然有codex5.5我直接写点skills和规则感觉就完事了，对我这边大部分业务来说，你觉得约束越多