每个人对微调（Fine-tuning）还是 RAG 都有自己的看法。浏览任何 AI 论坛，你都能看到充斥着架构图和基准测试结论的热烈讨论。大多数发表这些评论的人，从未在自己的数据上训练过模型，也从未亲眼目睹过 RAG 流水线在生产环境中无声无息地失败。

我花了几个月的时间进行实验。确切地说，是十二次实验。我微调了 LLM，微调了嵌入模型，还构建了六种不同的 RAG 配置。领域是金融预测，具体来说是尝试从杂乱的历史数据中预测充满噪声的市场结果。我对自己要求极高的统计标准，因为我想要的是真实的答案，而不是博客文章里的空谈。

大多数实验都失败了。事实证明，这些失败比任何侥幸的成功都更有用。

关于信号的残酷真相

在深入细节之前，这里有一个贯穿始终的教训。微调和 RAG 是改变模型“已知内容”或“所见内容”的工具。它们不是凭空制造信号的魔杖。如果你的底层数据中不包含真实的、可利用的模式，这些技术也创造不出来。它们只会帮你围绕随机噪声构建一个更具说服力的故事。

在金融预测中，这个陷阱尤其危险。市场的本质就是充满噪声的。当你把强大的 LLM 与历史价格数据挂钩，并加入检索或微调时，你并不会自动获得优势。你得到的只是一个更善于为“抛硬币”行为寻找合理化解释的方式。如果信号不存在，模型就会变得非常擅长对你撒谎。你需要首先确认这一点。

当规模导致“记忆”而非“学习”时

我的第一个重大错误是假设规模可以解决一切。我在正好 777 个训练样本上，对比测试了一个 140 亿参数的模型和一个 70 亿参数的模型。较大的模型取得了明显更好的 eval_loss。它的困惑度（perplexity）下降了。从纸面上看，它正在学习。

然后我查看了胜率，即模型做出正确预测的实际速率。14B 模型的表现明显差于 7B 模型。它记住了训练数据中的噪声。在样本量不足 3,000 个的情况下，较大的模型拥有足够的容量去对数据中的伪相关性和随机波动进行过拟合。它本质上构建了一个噪声查找表。

7B 模型受限于较小的容量，被迫学习更广泛的模式。它无法负担记住每一个细微特征的代价。如果你处理的是小数据集，请从较小的模型开始。规模并非免费的午餐。当数据稀疏时，规模可能会适得其反。

不要相信损失曲线

我学会了不再盯着损失曲线看。一个模型可以在提高 Token 级交叉熵的同时，在你在意的实际业务决策上表现得越来越差。这是因为语言建模损失奖励的是准确预测下一个 Token。在许多领域，尤其是金融领域，正确的决策与概率最高的下一个 Token 并不等同。

我见过一些模型能完美地复现训练文本的文风，但每次都会选错预测方向。损失值下降了，本金也随之下降了。请根据实际任务选择你的评估指标。如果你在对文档进行排序，请衡量排序质量；如果你在预测结果，请衡量决策准确性。永远不要让 eval_loss 替你决定模型。

微调仅在“外来词汇”上大放异彩

我针对两种不同的文本类型进行了嵌入模型微调实验。第一种使用的是标准的金融新闻和公开文件。微调后的嵌入模型与现成的版本表现完全一致。基础模型已经掌握了这种语言。我是在熟悉的领域进行微调。

第二个数据集充满了私有术语、内部代号和从未在公开互联网上出现过的领域特定缩写。在这里，微调将检索准确率提高了 79%。基础模型根本不知道这些术语是什么意思。微调教会了它本地词汇。

这重塑了我对整个过程的认知。微调并不是为了让模型在某种通用意义上变得更聪明。它是为了教它新的词汇、新的格式或一种特定的写作风格。如果你的数据看起来像互联网内容，那就跳过微调。如果你的数据使用的是基础模型从未见过的语言，那么微调就变得至关重要。

RAG 给你的是确定性，而非真相

I tested eight separate RAG configurations for prediction tasks. Across the board, adding retrieval changed roughly 30 percent of the model's decisions. That sounds impactful. It was not. Those changes were pure noise. The overall accuracy did not improve. What did change was the model's confidence. RAG made the system sound more certain, cite more sources, and produce longer justifications. All while being just as wrong.

This overconfidence is a product risk. A user sees citations and assumes the model has done its homework. In reality, it was doing sophisticated-looking guesswork.

The most painful lesson came from backtesting one RAG variant. It showed an 11 percent annual profit. On the surface, that looks like a winning strategy. But its AUC, the area under the ROC curve and a measure of classification skill, was 0.486. That is worse than a coin flip, which sits at 0.500. The profit was a fluke of the specific market period, not a repeatable edge. Using P&L alone as a metric is dangerous. Markets hand out lucky streaks all the time. You need statistical skill metrics to separate flukes from competence.

Know What Each Tool Actually Does

So where does this leave us? Use fine-tuning when the model needs to learn new words, specific formats, or a distinctive style. Use RAG when the model needs access to facts, code repositories, or institutional memory that lives outside its weights. Do not use either tool to discover signal in data that has none. If the underlying pattern is not there, retrieval and fine-tuning will only help you dress up the noise in a sharper suit.

The Real Bottleneck

The infrastructure for fine-tuning and RAG has never been easier to set up. You can spin up a pipeline in an afternoon. The technique is no longer the bottleneck. Evaluation is. Most teams skip the hard statistical work and celebrate vanity metrics instead. They ship systems that sound smart but fail silently.

Run honest tests before you spend money. Question your metrics. Check for overfitting. Make sure the model is actually better,