别再微调你的模型了。你的架构才是问题所在。

Demo 效果看起来很棒。但生产系统完全是另一回事。两者之间存在差距。

现在人们把一切都称为 Agent。一个带有记忆的聊天机器人是 Agent，一个带有循环的脚本也是 Agent。这种误解会导致工程错误。你最终会陷入对简单任务过度设计、对复杂任务设计不足的困境。

一个 Agent 需要一个目标。它不仅仅是遵循指令，它还会决定下一步该做什么。它能处理失败，并且知道何时停止。

使用这些规则来检查你的系统：

  • 如果每一步都需要人类引导，那它只是一个聊天界面。
  • 如果它能从失败的工具调用中恢复，它就是一个 Agent。
  • 如果它能将目标分解为子任务，它才是一个真正的 Agent。

成功的团队不会盲目追求新模型。他们构建的是针对特定用途的精细化流水线。他们专注于以下三点：

  • 工具设计：接口是否简洁？
  • 错误处理：当工具返回空结果时会发生什么？
  • 可观测性：你是否可以追踪每一个决策？

你使用的框架并不如你的设计模式重要。我曾在不同的框架下重建过架构，结果都是一样的。框架只是脚手架，架构才是建筑本身。

遵循这些模式：

  • 先规划，后执行。使用一个步骤进行推理，使用另一个独立的步骤进行行动。
  • 将检索与推理分离。获取上下文和使用上下文是两项不同的工作。
  • 使用显式的交接。当一个 Agent 将工作传递给另一个 Agent 时，请使用结构化日志。

RAG 已成为标准，但分块（chunking）往往做得不对。如果你对文档的分块处理不当，模型就会丢失上下文。这会导致幻觉。

如果你的 RAG 流水线返回了无用的结果，请检查你的分块和元数据。不要责怪 Embedding 模型。

工程挑战在于构建可以信任的系统。专注于治理、可观测性和可靠的工具使用。不要仅仅追求基准测试。

最优秀的工程师会专注于系统设计。他们会构建出他人可以维护并信任的 AI 系统。

来源：https://dev.to/aibughunter/stop-fine-tuning-your-model-your-architecture-is-the-problem-3kkg