项目为什么选择当前基座模型或架构？

核心回答

项目选择基座模型或架构，应从任务能力、工程约束和对照结果解释：模型在链路里负责什么，候选方案能否达到验收要求，在延迟、成本、资源和维护条件下，为什么当前方案更合适。参数规模和公开榜单用于筛选候选，最终要在自己的任务与工具环境中验证。

RAG 或 Agent 项目通常有不同的模型角色：意图识别负责分类或路由，Embedding 负责把文本映射到检索空间，Reranker 负责比较候选相关性，生成模型负责结合上下文回答或提出工具调用。各角色的目标不同，不必都用同一个大模型，也不能用生成模型的表现代替整条链路的效果。

如果选择某个指令模型，可以说明它对目标语言、领域术语、格式与工具调用的支持，以及在代表性任务上的质量和运行代价；如果选择较小模型，则要说明它在当前任务上保留了哪些能力，在哪些场景需要补问、转交或使用其他方案。当前方案应是约束下的选择，而不是“参数越大一定越好”。

先说明“基座”和“架构”分别指什么

项目里说的“基座模型”，有时泛指系统依赖的基础模型，不一定特指模型名中带 Base 的预训练版本。Base 模型通常更接近预训练产物；经过指令训练等后训练的版本，通常更适合直接响应用户指令、抽取字段和参与工具交互。名称是否包含 Instruct 并不统一，应看具体模型说明与训练阶段。

架构则是模型的计算结构，与具体权重版本不同。Encoder-only 常用于分类、表示学习等输入理解任务；Decoder-only 以自回归方式生成后续内容，适合对话和通用生成；Encoder-decoder 将输入表示与目标序列生成结合起来，常用于翻译、摘要等任务。这些是常见适配方向，不是对其他用途的绝对限制。

Dense 与 MoE 是另一条划分轴。MoE 根据路由选择部分专家参与计算，需要区分总参数与激活参数。激活参数影响每次计算量，但资源预算还要考虑专家权重如何存放、分布和传输，不能只按激活参数估算内存。是否更快、更省，要结合推理实现、硬件和并发负载比较。

把任务要求写成可检查的条件

以面向文档与 QA 的客服助手为参考，首先区分问题：中文术语与业务规则理解、依据检索材料回答、信息不足时澄清、按约定输出、需要时调用查询工具，以及长对话中保持关键条件。

资料有很多 Word、PDF、Markdown 或 QA 对，并不能直接推出需要多大参数的模型。先判断资料能否被正确解析和检索，关键证据是否进入上下文，再评生成模型能否忠实使用证据。若相关材料根本没有被召回，换一个更大的生成模型通常无法补齐这份缺失的依据。

对于标签固定的意图识别，可以把轻量分类模型、较小指令模型和现有规则列为候选；需要复杂多步决策的任务，则重点检查模型能否连续正确调用工具、使用反馈并及时停止。选择哪类方案由目标任务表现决定，不按任务名字固定分配最强模型。

模型能力与运行配置一起比较

同一个模型的推理模式、上下文模板、输出预算和量化方式都会影响结果。支持思考与非思考切换的模型，可以分别作为候选配置比较：额外推理是否改善了关键任务，增加的等待、输出和费用是否值得。简单分类不一定需要长推理，复杂任务也不应预设“思考越久越正确”。具体模式与工具调用兼容情况按模型和服务文档确认。

例如，Qwen 官方把 Qwen/Qwen3-8B 标为经过预训练与后训练的因果语言模型，并说明思考、非思考模式及聊天模板的用法。这些信息能帮助建立可复现的候选配置，但不意味着它已经适合某个客服项目，也不代表它是当前应优先选择的唯一型号。

工程条件同时包含：可用显存和内存、目标上下文长度、输出长度、并发、首 token 等待与端到端延迟，以及部署、许可和数据处理要求。权重能加载只是起点；KV cache、运行中间状态和推理优化也会消耗内存，长上下文与高并发会改变容量。量化或分布式部署可以调整资源需求，但需要重新检查质量、吞吐和延迟。

怎样用对照支持选择

先按硬条件缩小候选，再用代表性任务比较。固定资料快照、任务、工具协议、验收口径和可比运行预算，保存模型完整标识、权重或服务版本、模板、推理模式及关键生成设置。

分两层观察：局部测试用于比较当前角色的能力，例如意图标签、工具参数或候选排序；端到端测试用于确认客服问题是否被正确解决。统计关键场景的成功与失败、信息不足时的处理、格式和工具执行结果，同时记录延迟与完整运行成本。重要或波动较大的任务可以重复运行，避免凭一次回答做结论。

检查候选差异时，先解释失败发生在哪。小模型如果主要在少量复杂推理场景失误，可以评估是否值得增加专门处理；如果经常误解基础业务条件，则可能不适合作为该角色。大模型即使质量更好，也要看改善是否覆盖新增代价。可以保留几个各有优势的候选，而不必把多个指标强行合成一个排名。

可参考的项目回答方式

这个项目把模型选择拆到具体角色上：意图识别关心标签稳定性和响应，检索与重排关心相关证据能否进入上下文，生成模型关心业务理解、依据使用和必要的工具调用。我们选择候选时先看接口、部署和资源限制，再用同一批业务任务比较。当前模型适合的理由，需要对应到实际通过的场景、仍然存在的失败，以及与其他候选在成本和延迟上的取舍。如果选择较小模型，也要说明保留了哪些质量要求，而不只是说它响应更快。

可以据实际记录补上模型标识、对照对象和自己的选型工作。涉及架构时，再说明为何任务需要生成式能力、是否采用稀疏专家，以及部署实现能否支持这些选择。

常见追问

参数越大，哪些能力一定更好？

没有脱离训练数据、训练方法、后训练和任务条件的“一定”。更大规模可能提供更强的知识与推理能力，但跨代、跨任务和跨架构比较不能只看参数数。先提出预期改善的具体场景，再用任务验证。

为什么不用一个大模型同时做分类、检索和回答？

需要比较完整链路的质量和成本。独立表示模型与重排模型可以针对检索职责优化，小型分类器也可能满足固定标签任务；统一模型则可能简化接入。选择取决于实际收益，不能只凭组件少或模型强判断。

API 能调用、支持工具调用，就算接入成功了吗？

还要检查聊天模板、工具描述与参数、推理内容和最终结果的处理、异常及停止行为。协议连通只是接入基础，模型与当前 Agent 执行框架是否适配，需要用完整任务回归。

对应教程

参考资料