北京
有人在一台笔记本上搭了四种AI检索架构，用同一批文档、同一组问题做对照测试。测的不是谁跑得快，而是三种路线各自的取舍：普通RAG、Graph RAG，以及干脆把所有内容塞进前沿模型的上下文窗口。
四种架构，同一套题
实验的设计很朴素：文档不变，问题不变，只换检索方式。这样做的意义在于，把"架构差异"从"数据差异"里剥出来。同一道题，四种答法，谁多绕了路、谁多花了token，一目了然。
被摆上桌的三条路线各有各的性格：
- 普通RAG：按相似度捞片段，快，但容易漏掉片段之间的关系
- Graph RAG：先把文档织成图，再顺着关系找答案，重，但擅长多跳问题
- 全塞上下文：不检索，直接把材料喂给前沿模型，省事，但吃窗口
Graph RAG的代价藏在哪
Graph RAG不是免费的午餐。建图本身要花时间，查询时要沿着边跳，链路越长越慢。它的价值区间，恰恰是那些"答案不在任何单个片段里"的问题——需要把A和B连起来才能推出C。
反过来，如果问题本身就能在一个段落里找到答案，建图的那套开销基本白付。这也是这场对照实验最想回答的事：什么时候该上图谱，什么时候纯属过度设计。
上下文窗口不是万能解
把所有文档直接塞进前沿模型的上下文，听起来最省心。但窗口再大也有边界，材料一多，成本和延迟跟着涨。这条路线的适用面，取决于文档规模到底有多大。
三种路线没有绝对赢家，只有场景匹配。实验给出的不是排名，而是一张取舍表：问题复杂度、文档体量、能接受的延迟，三个变量决定你该选哪条路。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
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.
