北京
当用户问"Pinnacle Enterprises的续约风险如何"时，传统检索增强生成系统会怎么做？它把问题向量化，在2124个token的原始文本里跑余弦相似度，最后返回的片段里压根没提到这家公司。这就是BasicRAG在36道CRM测试题中的真实表现：答对14道，准确率38.9%。
问题出在数据结构上。CRM数据天生是关系型的——客户连着交易，交易连着负责人，负责人管着区域。但平面向量搜索把它当成文档库来用。我们基于TigerGraph构建的CRM Nexus系统，用图遍历替代了这种"大海捞针"。
测试数据是合成的，但设计得很真实：269万token，21318个节点，48201条边。7500笔交易（阶段、金额、负责人、结单日期），6000个客户（健康分、ARR、NPS、续约日），4318名员工（角色、部门、技能），外加5个产品及其竞品和路线图，5个部门及其Q4目标。所有记录都是CRM原生场景，没有维基百科填充。
核心查询用GSQL写成。以"getRelevantContext"为例：从客户节点出发，匹配名称，一跳到交易，再跳到负责人，三跳返回584个token。LLama 3.3 70B通过Groq调用，拿到的不是一堵文本墙，而是精确修剪过的关系子图。
技术实现有坑。TigerGraph社区版用Docker部署，第一次REST++调用超时，折腾几小时才发现是docker-compose里9000端口映射没配好。更大的门槛是GSQL本身——和SQL差异足够大，首批多跳查询编译报错让人摸不着头脑。直到搞懂accumulator（跨并行遍历的线程安全聚合变量）才豁然开朗。三跳查询写了一整天，但跑通后在本地4.8万边的图上稳定低于200毫秒。
评估环节我们刻意避开了"自己批作业"。生成答案用Llama 3.3 70B，独立裁判用Llama 4 Scout 17B，盲评输出打PASS/FAIL。语义层面用BERTScore F1，rescale_with_baseline=True，得分0.59，过了0.55的及格线。
结果对比很干脆：同样的36道题，同样的模型，只换检索方式。GraphRAG答对35道，准确率97.2%；BasicRAG答对14道，准确率38.9%。差距不是模型能力，是信息组织的范式。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
