trustgraph

背景：AI 应用的"幻觉"困境

当你向一个大语言模型（LLM）提问"我们公司去年 Q3 的营收是多少"时，它可能会自信满满地编造一个数字，而不是说"我不知道"。这种"幻觉"（Hallucination）问题，是企业落地 AI 时最难解决的顽疾之一。根本原因在于：LLM 自身的知识有截止日期，且它没有你的业务上下文。

传统解法是让 AI 联网搜索（RAG），但联网后依然面临另一个问题：LLM 无法真正"理解"企业内部知识的关联结构。文档 A 说"张三负责项目 X"，文档 B 说"项目 X 属于部门 Y"——如果 AI 无法将这种隐式关系串联起来，检索结果往往是碎片化的。

TrustGraph 尝试从另一个角度解决这个根本矛盾：不是让 AI 记住更多知识，而是给 AI 建造一张可解释的上下文关系图。

TrustGraph（trustgraph-ai/trustgraph，Apache-2.0 许可）是面向开源 AI 的确定性上下文工程平台，通过 Context Graph（上下文图谱）将大模型与企业知识库、业务数据源连接起来，使 AI Agent 能够以可解释、可审计的方式完成复杂推理任务。

项目起源与团队

TrustGraph 由 trustgraph.ai 团队开发维护，项目托管于 GitHub，采用 Apache-2.0 开源许可证。其定位介于底层 AI 基础设施和终端应用之间——既不是通用 LLM，也不是具体行业应用，而是构建可靠 AI Agent 所需的中间层编排框架。

项目的核心理念可以概括为一句话：让 AI 的"思考过程"变得透明且可验证。在企业场景中，AI 的输出需要能够追溯到具体的依据来源，而不仅仅是给出一个答案。TrustGraph 的架构设计从一开始就围绕这一目标展开。

核心技术：Context Graph 如何工作

TrustGraph 的核心技术栈包含三个层次：

1. Context Graph（上下文图谱）

Context Graph 是 TrustGraph 的核心抽象。它将企业知识表示为一张有向图，图的节点可以是：

• 文档段落（从 PDF、网页、非结构化文本中提取）
• 实体（人名、组织名、产品名等）
• 事件或关系

图的边则描述节点之间的语义关联，例如"文档 A 引用了文档 B 的数据"、"实体 X 是实体 Y 的子项目"。当用户提问时，TrustGraph 不是简单做向量相似度匹配，而是在图上做路径推理，找到从问题到答案的最短知识链路。

这种图谱推理的方式有两大优势：

• 可解释性强：AI 给出的每个结论都能追溯到具体的图节点和边
• 确定性高：图的遍历是规则驱动的，不会像纯向量检索那样因语义模糊而产生幻觉

2. Context Harness（上下文马具）

Context Harness 是 TrustGraph 设计的核心执行单元。你可以把它理解为一套可插拔的处理器管道。它由多个处理阶段组成，每个阶段负责特定的 AI 任务：

• 提取阶段：从各类数据源（PDF、网页、Confluence、Notion、数据库等）提取文本内容
• 嵌入阶段：将文本转为向量，用于语义检索
• 图谱构建阶段：将提取的实体和关系写入 Context Graph
• 推理阶段：在图谱上执行查询和推理

TrustGraph 内置了多种 Harness 实现，包括 trustgraph-docling（文档解析）、trustgraph-ocr（光学字符识别）、trustgraph-unstructured（非结构化数据处理）等，覆盖了企业数据的主要来源。

3. 多后端 LLM 支持

TrustGraph 并不绑定某个特定的大模型。它通过标准化的接口，连接到多种 LLM 后端：

后端	说明
OpenAI	GPT-4o、GPT-4o-mini 等
Anthropic	Claude 3.5 Sonnet、Claude 3 Opus
AWS Bedrock	Claude（通过 AWS 部署，兼顾数据合规）
Google Vertex AI	Gemini 系列
Ollama	本地部署 Llama、Mistral 等开源模型

这种灵活性让企业可以根据数据安全要求、性能需求和成本预算，选择最合适的 LLM 方案，而无需更换整个技术栈。

技术架构解析

TrustGraph 的代码库采用 Python 单体仓库（monorepo） 结构，主要子包包括：

子包	功能
trustgraph-base	核心基座：消息队列（Pulsar）、指标采集（Prometheus）
trustgraph-cli	命令行工具：部署配置生成、服务管理
trustgraph-flow	数据流引擎：编排处理器管道
trustgraph-mcp	MCP 协议实现：与 Claude Desktop 等工具集成
trustgraph-bedrock	AWS Bedrock 后端
trustgraph-vertexai	Google Vertex AI 后端
trustgraph-embeddings-hf	HuggingFace 嵌入模型集成
trustgraph-docling	文档解析（PDF、Word、HTML）
trustgraph-ocr	光学字符识别

主要依赖包括：LangChain（编排框架）、RDFLib（图谱管理）、PyMilvus（向量数据库）、Sentence-Transformers（嵌入模型）、Pulsar（消息队列）、PyTorch（深度学习）。项目配置使用 pyproject.toml，发布到 PyPI。

容器化方面，项目提供了 9 个 Containerfile（基于 Fedora 42 + Python 3.13），覆盖各个服务组件，支持通过 Podman 构建。macOS 用户可以通过 ./install_trustgraph.sh 交互式安装脚本一键部署。

上手体验

安装方式

TrustGraph 支持多种安装路径：

macOS 交互式安装（推荐）：

./install_trustgraph.sh

安装脚本会自动检测硬件配置，推荐合适的 LLM 模式（本地 Ollama 或云端 OpenAI），安装依赖项，运行测试套件，生成 Docker Compose 部署文件，并启动服务。

pip 安装：

pip install trustgraph-base trustgraph-cli

手动容器部署： 使用 containers/ 目录下的 Containerfile.* 构建各组件镜像，通过 Podman 运行。

Web UI：Workbench

TrustGraph 提供了一个名为 Workbench 的 Web 界面（默认 http://localhost:8888），用于：

• 可视化浏览 Context Graph
• 上传和管理文档
• 发起问答查询并查看推理路径
• 监控服务健康状态

硬件需求

组件	最低要求
CPU	4 核
内存	16 GB（使用本地 Ollama LLM 建议更高）
GPU	推荐（使用本地模型时建议 8GB+ 显存）

局限与挑战

TrustGraph 并非银弹，了解其局限性有助于做出合理的技术选型：

1. 图谱构建成本较高：初始构建 Context Graph 需要对知识库进行实体抽取和关系识别，这个过程依赖 LLM 的准确性，且耗时较长。对于超大规模知识库，图谱更新的实时性是一大挑战。

2. 容器部署复杂度：项目没有提供开箱即用的 docker-compose.yml，需要通过 install_trustgraph.sh 脚本动态生成部署配置。手动部署时需要理解多个容器组件之间的依赖关系。

3. 偏向底层框架：TrustGraph 提供的是构建块而非完整应用，开发团队需要具备 AI 和图数据库的交叉知识才能有效使用。

4. 文档和社区仍在成长：作为相对新兴的项目，其详细使用案例和企业级生产部署的最佳实践还在积累中。

行业意义与趋势

TrustGraph 代表的实际上是 Context Engineering（上下文工程） 这一新兴技术方向。在 RAG（检索增强生成）已经广泛普及的背景下，Context Engineering 试图更进一步——不只是把相关文档塞给 LLM，而是构建一个结构化的、可推理的知识层。

这一方向的核心假设是：AI Agent 的可靠性不仅取决于模型本身的能力，还取决于它所拥有的上下文的质量和结构。图谱化的上下文能够支撑更复杂的多跳推理，而这是纯向量检索难以做到的。

从市场趋势看，随着企业 AI 应用从"单点问答"走向"复杂任务自动化"，对可解释 AI 的需求会持续增长。TrustGraph 的确定性推理路径设计，直接回应了这一趋势。

总结

TrustGraph 是一个定位清晰、技术有深度的 AI Agent 中间件项目。它通过 Context Graph 和 Context Harness 构建了一个可解释、可验证的 AI 推理层，解决了大模型幻觉和推理不可靠的痛点。Apache-2.0 许可使其适合企业内部分发使用，多后端 LLM 支持提供了部署灵活性。适合有一定 AI 研发能力的团队，用于构建企业内部知识问答、复杂决策支持等场景。

主要优势：可解释性强、多 LLM 后端、模块化设计、开源透明。 主要门槛：图谱构建成本、容器部署复杂度、需要一定 AI 技术背景。

项目链接：https://github.com/trustgraph-ai/trustgraph