T-RAG=RAG+微调+实体识别

T-RAG 的核心思路可以这样理解：它把 RAG 架构、开源的微调语言模型（LLM），以及实体树向量数据库这三样东西整合在一起，专门用来做上下文检索。简单说，就是给传统的检索增强生成加了一棵“实体树”，让模型能更聪明地定位信息。

背景介绍

大型语言模型在各个领域用得越来越广，尤其是在

里。但这里头有个现实问题：和是底线，没办法直接套用现成的公共 API。所以定制化成了绕不开的路。下面要讲的是一个实际案例——用 Tree-RAG（T-RAG）系统在企业私有文档上部署 LLM 问答应用的经验。这个方案把实体层级信息揉进了检索过程，效果不错，评估结果也证实了它的有效性。这些经验对于想把 LLM 真正落到实际业务中的团队来说，挺有参考价值。

数据隐私

因为文档本身敏感，安全风险是第一道坎。

。必须上开源模型，而且得部署在内网环境。除了这个，有限的计算资源、基于现有文档拼出的小训练集，也都是实实在在的挑战。要在这个条件下保证用户问什么都能给出靠谱、精确的答案，背后得做大量的定制化工作，一系列复杂的问题自然就冒出来了。

技术亮点

这项研究真正有价值的地方在于，它提出了一种

。不光如此，他们还整了一个新的评估指标，叫“”。这个指标不光看答案对不对，还会看你回答时是不是额外提供了问题范围之外但仍有用的信息——算是从实用角度给回复质量打了个分。

T-RAG

Tree-RAG（T-RAG）的工作流程其实挺清晰的。用户问一个问题，系统先从向量数据库里搜出相关的文档片段，作为 LLM 的背景知识。如果问题里提到了任何和组织相关的实体（比如某个部门、某个人），系统就会从实体树里把这些实体的信息拎出来，一并加到背景知识里。最后，经过微调的 Llama-27B 模型基于这些信息给出回答。

实体树

T-RAG 一个很突出的特点，就是在向量数据库之外额外弄了个实体树（entities tree）来辅助上下文检索。这棵树里存的是和企业组织相关的内部实体信息，以及它们之间的层级结构。每个节点代表一个实体，父节点说明它属于哪个大组。检索的时候，T-RAG 会拿实体树去增强从向量数据库里拿到的上下文。具体怎么查询和生成上下文呢？过程如下：

1. 一个解析器模块先扫描用户的问题，看有没有组织内部实体名称的关键字。
2. 如果找到了一个或几个匹配项，就从实体树里提取每个匹配实体的详细信息。
3. 把这些细节转成文字描述，告诉模型这个实体叫什么、在组织层级里处于什么位置。
4. 然后把这段信息跟从向量数据库搜到的文档块组合在一起，拼出最终的上下文。
5. 这样一搞，当用户问起某个具体实体时，模型手里就有了关于这个实体及其层级位置的结构化知识，回答自然更精准。

结合上头的图，用一个组织结构图的例子就能直观展示树搜索和检索的过程：

1. 除了拿相关的背景文档，系统还会用 spaCy 库加自定义规则，识别出问题里的命名实体。
2. 如果问题包含一个或多个实体，就从实体树里提取该实体的层级位置信息，再转成文本。
3. 这些文本和检索到的文档拼在一起，成为最终的上下文。
4. 特别说明一下：如果用户问题里压根没提任何实体，系统就直接跳过树搜索，只靠检索文档提供上下文。

总结

这项研究让人挺受启发的，因为它把 RAG、模型微调和实体识别给串起来了。一方面，靠内部部署的开源模型解决了数据隐私的硬伤；另一方面，实实在在地压低了推理延迟和 token 使用成本，还能照顾到不同地区用户的需求。另外，用 spaCy 框架做实体搜索和上下文生成，这个思路也很值得借鉴。最重要的还不是理论——这背后是构建实际 LLM 应用的经验总结，落到地上干活的那种，价值很高。