可能需要为前沿模型设置数学+代码基准（大语言模型悄然取代数学）[D]

大家好。我发现在当前前沿模型中存在一些问题，特此分享。# 数学与代码的幻觉 > 当把数学和代码塞进同一个提示词时，所导致的失败记录。---## 案例 1### 初始提示词（`p0`）如果输入以下提示词：```pythonmake code implementation of sub rieman applied to mitigate hallucination in llm using lora, pretrained llm(such as qwen, mistral, llama,etc) and training pipeline in pytorch.```会生成如下代码：```python..._, singular_values, vh = torch.linalg.svd(centered.float(), full_matrices=False) # from gpt...```---### 对比| 提示词类型 | 结果 || --- | --- || 要求将子黎曼几何嵌入LLM训练代码（如初始提示词 `p0`） | 生成了使用 SVD、PCA、投影等方法的代码 || 不要求将子黎曼几何嵌入LLM训练代码，只简单要求“实现子黎曼几何”或“编写子黎曼几何代码” | 生成了涉及测地线等概念的优秀代码实现（子黎曼几何是几何学的一个领域；测地线指两点间的最优距离）。因为计算测地线成本高且实现复杂，便代之以常用且成本低的 SVD、PCA、投影等方法。但 SVD、PCA、投影并非黎曼几何。---### 主要观察```text仅要求包含数学的代码 |`-- 代码写得很好```然而：```text结合代码与数学 |`-- LLM在不告知用户的情况下，随意更改应使用的数学公式```再次：```text要求实现子黎曼几何 |`-- 它实现得很好```但：```text将子黎曼几何与编码元素结合 |`-- 问题出现了```换句话说：> 当要求编写仅包含数学内容的代码时，它写得很好。但一旦代码与数学混合，LLM就会在不告知用户的情况下，随意更改应使用的数学公式。再强调一次：如果只要求实现子黎曼几何，它做得很好；问题出现在将编码元素与子黎曼几何结合时。---## 案例 2如果要求编写使用隐藏空间中潜在向量的LLM训练代码（对我而言，`z`是某个`nn`模块的输出），它有时会编写让`|z|`的幅度等于1或更小的代码。```text隐藏空间的潜在向量 |`-- z：nn 模块的输出 | |-- 使 |z| 的幅度等于 1 `-- 或者使 |z| 的幅度变小```github 链接：genji970/math_code_hallucination：一份记录，展示当数学和代码组合在一个提示词中时，LLM 如何悄无声息地用更简单的计算替代品替换高难度的数学组件。