CLARC: C/C++ Benchmark for Robust Code Search

本文提出了 CLARC，这是一个基于真实 GitHub 仓库构建的 C/C++ 代码搜索基准，通过自动化流水线生成包含编译性验证、依赖分类及匿名化等挑战性场景的数据集，揭示了现有模型过度依赖词汇特征而缺乏语义理解能力的现状。

要点

这篇论文介绍了一个名为 CLARC 的新工具，它的目的是给“代码搜索引擎”做一次严格的“体检”，看看它们到底是不是真的“懂”代码，还是只是在“死记硬背”关键词。

我们可以把这篇论文的故事想象成招聘一位图书管理员的过程。

1. 背景：现在的图书管理员有点“偷懒”

在软件开发的世界里，程序员需要在一个巨大的代码库（就像一座巨大的图书馆）里寻找特定的功能代码。以前，大家主要用 Python 语言来测试这些搜索工具，而且测试方法比较“表面”。

这就好比在测试图书管理员时，只让他找书名里带有“苹果”的书。如果管理员看到《红苹果》就找到了，你就觉得他很厉害。但实际上，他可能根本没读过书，只是记住了“苹果”这两个字。一旦书名改成《红色的果实》，他就找不到了。

现有的测试存在三个大问题：

1. 语言单一：只考 Python，不考 C/C++（这是系统底层的核心语言，就像图书馆的基石）。
2. 环境虚假：给的代码片段经常缺胳膊少腿（比如缺少必要的引用），就像给管理员一本缺页的书，让他猜内容。
3. 抗干扰能力差：没测试过如果书名被涂改、或者书被翻译成了另一种语言，管理员还能不能找到。

2. 解决方案：CLARC —— 一场“魔鬼训练”

作者团队（来自南加州大学）建立了一个名为 CLARC 的测试基准。你可以把它想象成一个**“代码奥林匹克”考场**，专门用来测试代码搜索模型的“真功夫”。

这个考场有三个独特的“关卡”：

• 关卡一：真实环境（ compilability）
  所有的代码都是真实的、能运行的。就像给管理员一本完整的、装订好的书，而不是散乱的几页纸。
• 关卡二：难度分级（依赖复杂度）
  • 简单题：代码只用了标准库（就像书里只用了常见词汇）。
  • 中等题：代码用了自定义的类型（就像书里出现了一些生僻的专业术语）。
    困难题**：代码调用了其他辅助函数（就像书里引用了其他章节的内容，需要管理员有全局观）。
• 关卡三：干扰项（Robustness Stress Tests）
  这是最精彩的部分！为了测试管理员是不是真的“懂”内容，考官故意把书“毁”了：
  • 匿名化（Neutralized）：把书里所有的“人名”、“地名”都改成“张三”、“李四”、“王五”。如果管理员还能找到书，说明他读懂了故事逻辑；如果找不到，说明他只是在背名字。
  • 随机化（Randomized）：把名字改成乱码（如 x9z2）。
  • 底层语言（Assembly/Wasm）：把书从“中文”翻译成“摩斯密码”或“二进制代码”。这相当于把书的内容压缩成了最原始的信号，看管理员能不能理解核心逻辑。

3. 实验结果：令人震惊的“翻车”现场

作者找来了 6 个目前最顶尖的“图书管理员”（AI 模型）来参加考试。结果非常残酷：

• 在正常考试中：这些 AI 表现很好，得分很高。
• 一旦“改名”或“翻译”：它们的得分断崖式下跌。
  • 比如，把变量名从 calculate_tax（计算税款）改成 func_a，AI 就完全不知道这是在干什么了。
  • 把代码编译成机器语言（汇编），AI 更是直接“晕”了，完全找不到北。

结论：这些 AI 模型其实并没有真正理解代码的逻辑和语义（故事讲了什么），它们只是太擅长死记硬背关键词（记住了“税款”这个词）。一旦关键词消失，它们就“失忆”了。

4. 为什么这很重要？

这就好比：

• 现在的 AI：像是一个只会背字典的学生。你问它“苹果”，它知道。你问它“红色的水果”，它可能就懵了。
• 我们需要的 AI：应该像是一个真正懂编程的工程师。即使你把变量名全改了，或者把代码变成了机器码，他依然能看懂：“哦，这段代码是在做排序，那段是在算利息。”

5. 总结与未来

这篇论文的核心贡献在于：

1. 造了一个新考场（CLARC）：专门用来测试 C/C++ 代码搜索，并且包含了各种“捣乱”的测试场景。
2. 揭露了真相：目前的 AI 在代码搜索上，过度依赖表面文字，缺乏真正的理解能力。
3. 提供了数据：他们公开了数据集，让全世界的研究者可以来训练更聪明的 AI，让它们学会“透过现象看本质”，不再被变量名或代码格式的变化所迷惑。

一句话总结：
CLARC 就像给现在的 AI 代码搜索工具做了一次“去伪存真”的考试，发现它们大多只是“背题机器”，而不是“理解大师”。作者希望通过这个新工具，逼迫未来的 AI 真正学会理解代码的逻辑，而不仅仅是记住代码的名字。

技术摘要

这是一篇发表于 ICLR 2026 的论文，题为 CLARC: C/C++ BENCHMARK FOR ROBUST CODE SEARCH（CLARC：面向鲁棒性代码搜索的 C/C++ 基准）。

以下是对该论文的详细技术总结：

1. 研究背景与问题 (Problem)

现有的代码搜索基准测试存在显著局限性，导致难以评估模型在真实场景下的鲁棒性和语义理解能力：

• 语言偏差：大多数基准（如 CodeSearchNet, CoSQA 等）主要关注 Python，忽视了 C/C++ 等系统级编程语言，而这些语言在底层系统和嵌入式开发中至关重要。
• 缺乏可编译性：现有数据集中的代码片段往往缺少必要的 include 语句、辅助函数或依赖定义，导致代码无法编译，无法反映真实的开发环境。
• 鲁棒性测试缺失：现有基准很少评估模型在面对文本扰动（如变量重命名、混淆）或低层级语言（如汇编、WebAssembly）时的表现。这掩盖了模型是否真正理解代码语义，还是仅仅依赖表面的词汇特征（Lexical Features）。
• 对抗性场景忽视：随着代码混淆和对抗性攻击的增多，缺乏对模型在标识符匿名化或低层表示下检索能力的评估。

2. 方法论 (Methodology)

作者提出了 CLARC (C/C++ LAnguage Retrieval with Anonymized Code)，这是一个基于真实 GitHub 仓库构建的自动化管道生成的 C/C++ 代码搜索基准。

2.1 数据集构建流程

• 数据收集：从 144 个流行的 GitHub C/C++ 仓库中提取函数，确保代码在预定义的白名单标准库环境下完全可编译。
• 分类体系：根据依赖复杂度将代码分为三组：
  • Group 1：仅依赖标准库函数和类型。
  • Group 2：依赖标准库但使用了自定义变量类型。
  • Group 3：调用用户定义的辅助函数（Helper Functions）。进一步细分为 Short（主函数与辅助函数分离）和 Long（合并为单一代码块）。
• 查询生成 (Query Formation)：利用大语言模型（LLM，如 o3-mini 和 grok-4）自动生成自然语言查询。
  • 质量控制：通过严格的双盲人工评分和假设检验 (Hypothesis Testing) 验证 LLM 生成的查询质量。结果显示 LLM 生成的查询质量与人类专家相当甚至更优。
• 鲁棒性设置 (Robustness Settings)：为了测试模型对表面特征的依赖程度，设计了四种特殊设置：
  • Neutralized (中和)：将标识符替换为通用占位符（如 func_a, var_b），保留结构但去除语义命名。
  • Randomized (随机化)：将标识符替换为完全随机的字符串，彻底消除词汇线索。
  • Assembly (汇编)：将代码编译为 x86 汇编，去除大部分高级语言标识符。
  • WebAssembly (Wasm)：将代码编译为 WebAssembly (.wat 格式)，完全匿名化。

2.2 实验设置

• 数据规模：包含 1,245 个评估对（Evaluation）和 5,472 个训练对（Training）。
• 评估模型：测试了 6 种最先进的模型，包括：
  • 传统基线：BM25。
  • 开源编码器：CodeT5+, OASIS, Nomic-emb-code。
  • 闭源/通用模型：OpenAI-text-embedding-large, Voyage-code-3。
• 评估指标：NDCG, MRR, MAP, Recall@k。

3. 关键贡献 (Key Contributions)

1. CLARC 基准发布：首个专注于 C/C++、完全可编译、且包含多样化鲁棒性测试（匿名化、汇编、Wasm）的代码搜索基准。
2. 自动化构建管道：设计了一套可扩展的自动化流程，利用 LLM 生成查询并通过统计假设检验验证质量，为未来构建高质量数据集提供了范式。
3. 揭示模型缺陷：通过实验揭示了当前最先进（SOTA）的代码搜索模型严重依赖表面词汇特征（如变量名、函数名），而非深层的语义理解。

4. 实验结果 (Results)

• 标准设置表现：在标准设置下，较新的模型（如 Voyage-code-3, Nomic-emb-code, OASIS）表现优异，NDCG 可达 88% 以上。
• 标识符匿名化导致性能骤降：
  • 当进入 Neutralized 和 Randomized 设置时，所有模型的性能均出现急剧下降。
  • 例如，Voyage-code-3 在 Group 1 的 NDCG 从 88.99 降至 83.85 (Neutralized) 和 83.85 (Randomized)，而在 Group 3 中下降更为显著。
  • 结论：模型高度依赖标识符名称进行匹配，一旦名称被混淆，其检索能力大幅减弱，证明其缺乏真正的语义理解。
• 低层级语言表现极差：
  • 在 Assembly 和 WebAssembly 设置下，模型性能进一步崩塌。OpenAI 和 Voyage 模型在汇编语言上的 NDCG 甚至低于 35%。
  • 这表明通用或代码专用模型难以处理低层级指令的语义映射。
• 微调的局限性：
  • 作者尝试对 CodeT5+ 和 OASIS 进行监督微调。虽然微调提升了标准设置下的表现，但无法消除标准设置与匿名化设置之间的性能差距。
  • 这证明简单的监督微调不足以解决鲁棒性缺陷，模型并未学会真正的语义泛化。

5. 意义与影响 (Significance)

• 重新定义代码搜索评估：指出当前的高分可能源于对词汇特征的过拟合，而非语义理解。未来的基准必须包含匿名化和低层语言测试。
• 推动鲁棒性研究：CLARC 为研究如何使模型在代码混淆、反编译或对抗性攻击下保持鲁棒性提供了关键测试床。
• 系统级语言支持：填补了 C/C++ 代码搜索基准的空白，对于系统编程、安全分析和嵌入式开发领域的 AI 应用至关重要。
• 开源贡献：数据集和代码已公开，促进了社区在可编译、高鲁棒性代码检索方向的研究。

总结：CLARC 通过引入严格的编译性要求和多样化的鲁棒性测试场景，有力地证明了当前 SOTA 代码搜索模型在语义理解上的不足，特别是它们对表面词汇特征的过度依赖。该工作呼吁社区开发更能理解代码深层逻辑和语义的模型，而不仅仅是记忆标识符。