用户任务
将真实查询写成任务级用例，并标记期待的答案、必要证据与不可接受的风险。
← 返回精选作品
CASE 02 / Knowledge Graph System个人项目 · 功能原型
让大模型的回答，经得起测试。
一个把文档转换、结构化知识、混合检索、引用问答、质量评测与只读 MCP 接入串成一条可检查链路的 GraphRAG 知识工作台。
上线一个 AI 功能，先回答它在什么情况下不应发布。
RAG 的可靠性从文档进入系统的那一刻就开始：格式转换可能污染内容，资源异常可能拖住任务，摄取并发和进度丢失会让状态失真；即使资料顺利入库，证据仍可能没有召回、上下文可能不相关、回答可能超出材料、引用也可能无法支撑结论。若只靠 Demo 体验或一个总分，团队无法解释问题在哪，也无法判断复杂 GraphRAG 方案是否值得承担额外成本。
不只测答案，从资料进入到引用返回都要可观察。
一次失败只有被定位，才有可执行的修复方向。评测不追求一个漂亮总分，而是沿着摄入、检索、上下文、生成与引用建立可观察的判断。
资料与证据召回
先检查资料是否被正确摄入、正确材料是否进入上下文，再判断图谱、混合检索与重排是否真的带来收益。
回答与引用忠实
回答必须受上下文预算约束，引用要能回到支持结论的原文；流畅、完整的表达不能掩盖无依据补全或错误推断。
引用可核验
用户应能沿着引用回到支持结论的原文，而不是看到形式上存在、实际无关的来源。
TEST SET
金标答案与证据来源，让“答对”有可复现的参照。
BASELINE
和关键词、向量等方案对照，避免把复杂度当成效果。
CALIBRATION
模型评审配合人工抽查，校准自动评分与真实判断的差异。
一份分数不够，还要能解释错误发生在哪里。
建立一套从输入可信到输出可验证的测试闭环：用目标用户任务定义“答对”，以金标与基线量化不同检索方案的收益，用错误分类定位问题，并把质量、风险、延迟与成本共同转化为发布决策。
先把资料摄入当作质量门槛
用 anydoc 处理 PDF、Word、TXT 与 Markdown，并在上传时做扩展名、文件特征和大小校验；转换失败返回明确错误并清理文件，后台摄取由并发闸门控制，排队中的文档保持 pending。
- 为什么
- 错误的原文、失控的资源消耗或丢失的进度会污染后续所有指标。把失败变成可见状态，把并发收敛在可控边界内，才能让“没有回答”与“回答错误”被正确区分。
- 测试代价
- 扫描版 PDF 不做无依据的 OCR，资源或转换异常会进入人工处理；进度事件落库和状态清理增加了持久化成本，但换来了可重连、可追溯的摄取过程。
把 GraphRAG 设计成可比较的检索通道
用统一 retrieve 编排多查询、向量、BM25 与可选图谱通道，再经过 RRF、重排、同段/邻接扩展和缓存；图谱模式支持 auto、on、off，便于和更简单的检索方案对照。
- 为什么
- 图谱不是天然正确答案。只有把它放进同一条检索链路，比较召回、排序、回答质量与代价，才能判断结构化关系是否真的帮助目标任务。
- 测试代价
- 多通道、重排和扩展会增加延迟、模型调用与内存缓存压力；缓存、限流和并发闸门仍以进程为边界，具体门槛必须按场景校准。
让回答和外部接入都保留判断边界
用引用质量等级、引用覆盖率和上下文预算约束回答；对闲聊与应拒答问题绕过检索，并通过显式 user_id、token 和只读工具把知识能力接给外部 Agent。
- 为什么
- 用户需要知道答案依据什么，外部 Agent 也不应默认拥有写入或越权能力。把可核验来源、拒答边界和只读权限写进产品契约，才能让能力被安全复用。
- 测试代价
- 引用覆盖率和模型裁判仍是离线信号，不能替代真实用户反馈；MCP 当前只覆盖只读知识查询，权限、采纳、纠错与线上成本还需继续验证。
用一组问题，检查四个不同的质量切面。
选择示例问题，查看从任务定义、链路定位到方法迁移的评测思路。内容为固定说明，不是实时检索或线上结果。
选择问题，查看对应的评测切面。
示例回答 / 01
把真实查询写成任务级用例，标记期待的证据、答案和引用来源，先明确什么算解决了用户问题。
示例文档 A · 评测任务设计“没有任务标准，回答再流畅也无法判断是否真的有效。”
固定评测示例 · 引用为自编说明文字 · 非实时检索结果
发布不是“分高就上”，而是确认收益能够覆盖风险。
工程上已有安全边界明确的文档转换、实体关系抽取、混合检索、引用问答、进度恢复、日志与重试策略，以及评测框架和只读 MCP 服务，可支撑内部验证与后续迭代。它仍是需要真实语料校准的工程原型：当前没有真实用户试点、线上效果或稳定性数据，扫描版 PDF 也会明确进入人工 OCR 边界；上线前还需校准金标质量、模型裁判一致性、敏感文档权限，以及效果、延迟和成本之间的阈值。
有任务集，也有基线
先确保每一类关键任务都能被复现测试，并能与更简单的方案进行对照。
高风险错误仍不可接受
无依据回答、错误引用、敏感文档越权等问题不能被平均分掩盖，必须成为独立门槛。
用真实查询校准离线判断
记录用户是否采信回答、打开引用或提交纠错，再将这些反馈写回持续回归测试。
IMPLEMENTATION EVIDENCE
以下仓库内容说明评测与检索链路已有实现基础；不等同于未经复跑的效果结论。
可靠的文档摄入
上传入口校验文件类型、大小与文件特征；anydoc 转换失败会清理临时文件并返回可解释的失败状态，后台摄取还通过并发闸门与持久化进度控制过程。
backend/app/api/documents.py统一检索与图谱增强
可查看多查询、向量、BM25、图谱通道、RRF、重排、邻接扩展和缓存如何被统一编排；评测需覆盖这些环节，才能定位一次失败发生在哪里。
backend/app/services/retriever.py评测框架
仓库提供 Hit@K、MRR、Precision、Recall、nDCG、关键词覆盖、模型裁判与金标用例，构成从测试集到评分的基础。本作品集未复跑完整评测，因此不展示未经核验的提升百分比。
backend/eval/runner.py只读 MCP 接入
MCP Server 暴露搜索知识、搜索图谱、实体详情和文档列表四类只读工具，要求显式 token 与 user_id；它是外部 Agent 的接入边界，不是写入通道。
backend/mcp_server/server.py可探索的图谱
产品提供节点搜索、关系查看与图谱导出。图谱增强是否值得保留，需要用目标任务、质量收益与额外成本进行对照验证；本页图谱是固定示例。
frontend/src/components/GraphPanel.vue当前边界
当前案例没有真实用户的满意度、留存、线上质量或稳定性数据。公开演示使用固定文档片段，不上传文件、不调用模型，也不代表生产检索效果；扫描版 PDF、真实权限配置、MCP 线上调用与多进程部署仍有明确边界，离线分数更不能替代真实使用中的可靠性验证。