至于痛点一。向量检索总是漏掉“语义鸿沟”里的关键函数

在实际项目里你经常会遇到这样的问题：搜索关键词时程序只返回了一部分相关代码，却漏掉了真正的实现入口。比如查询 process payment and create Stripe charge 时只命中了一个函数，而真正需要的函数 calculate_order_total 全部被忽略。

原因很直观——纯文本向量模型无法捕捉“调用关系”这一层业务协同信息。它只关注词汇重叠，导致距离很远的相关代码被误判为无关。

至于痛点二，图提高检索好像没用。甚至让别的查询变差

你可能已经尝试过将调用图加入检索流程，后来发现整体评估指标和纯向量相差无几。更糟的是一些本来得分满分的查询反而出现了下降。

说到这让人怀疑。到底是图提高没效果，还是使用方式不当？

为什么两种方法看似相等但背后有不同影响？老实说，

总分相同是因为两股力量互相抵消：

• A 场景: 图提高帮助抓住了因语义距离远而被遗漏的关键函数。
• B 场景: 图 带来了噪声，使得原本靠向量排序命中的函数被挤出 top‑k。

从案例分析来看。Q8 与 Q1 的对比

Q8

• 向量检索：未命中 calculate_order_total
• 图提高：通过 BFS 从种子 process_checkout 向下 两跳，成功把缺失函数拉回候选集。

Q1

• 向量检索：P0 提前命中两个目标函数。
• 图提高：BFS 扩大候选集后新来的“结构相关但查询无关”的函数稀释了排序，使得其中一个目标被挤出 top‑k。

如何避免“ 引起的噪声”？

1️⃣ 只走 “CALLS” 边

a) “谁调用我”往往会把大量无关业务逻辑拉进来。优先只沿正向依赖边 可以显著降低噪声。

2️⃣ 限定模块范围内

a) 跨模块调用常见于工具类，例如数据库访问器；这些节点往往与业务功能无直接关联。说起来，过滤掉跨模块边能保持候选集质量。

3️⃣ 控制跳数 仅用最小必要步数即可满足需求。例如在支付流程里从入口到实现节点仅需一步或两步即可覆盖完整业务链。怎么说呢，

4️⃣ 将调用关系嵌入 embedding 内容，而非检索时再做 BFS 在建立索引时将每个函数 chunk 加上如下元数据行：

{
"content": (
"# module: payment
"
"# called_by: process_checkout
"
"# calls:
"
"def calculate_order_total:
"
" ...
"
)。"metadata": {"name": "calculate_order_total","module": "payment"}
}

A 向量包含 “called_by” 信息后即使使用者搜索的是入口关键词，也能直接在 embedding 中感知到下游实现，从而无需额外 步骤。

优点概览的观点是。

• No candidate pool explosion → no noise introduced.
• No extra re‑ranking step → faster retrieval.
• The structural signal is baked into vector itself → pure similarity search remains accurate.

& 接下来行动计划

1. Total Recall@k 看似不变，却掩盖了内部波动。
2. Simpler graph traversal = double‑edged sword.
3. MVP 的改进方案是：把结构信息编码进 embedding 内容，而不是在检索时再做 BFS
4. The next experiment will validate this approach by fixing Q8 without harming Q1.