这两年国产大模型发展得特别快。

从最早的文心一言、通义千问，到后来的智谱GLM、月之暗面Kimi、DeepSeek，再到现在各种开源和闭源模型层出不穷，国产大模型的能力越来越强，应用也越来越广泛。

我们团队从去年开始在实际项目中大规模使用国产大模型，做过智能客服、内容生成、数据分析、代码辅助等多个场景。在这个过程中踩了很多坑，也积累了不少经验。

这篇文章我想总结一下使用国产大模型的最佳实践。从模型选择、Prompt工程到部署优化、成本控制，聊聊那些踩过的坑和总结的方法论。

如果你也在用或者打算用国产大模型，希望这些经验能帮你少走一些弯路。

先说明一下，我主要基于2025年上半年的模型情况来写，大模型发展很快，有些结论可能会随着模型的迭代而过时。而且不同的项目场景差异很大，我的经验不一定适用于所有情况，需要结合实际灵活运用。

模型选择：没有最好的，只有最合适的

第一个要解决的问题就是模型选择。

现在国产大模型太多了，光是主流的就有十几个，每个模型都有自己的特点和优势。很多人刚开始的时候会纠结，到底选哪个模型好？是不是选最贵的、参数最大的就一定好？

我的经验是，没有最好的模型，只有最合适的模型。选择模型的时候要根据你的具体场景来决定，而不是盲目追求最强的模型。

我们在选择模型的时候主要考虑以下几个维度：

第一是能力匹配。不同的模型在不同的任务上表现不一样。有的模型擅长中文理解和生成，有的擅长代码，有的擅长数学推理，有的擅长长文本。你要根据自己的任务类型，选择在这个任务上表现好的模型。

比如我们做智能客服，主要是中文对话和问答，就选中文能力强的模型。做代码辅助，就选代码能力强的模型。做长文档摘要，就选上下文窗口大的模型。

第二是成本控制。大模型的调用是要花钱的，不同模型的价格差异很大。有的模型很便宜，几分钱就能调用一次；有的模型很贵，一次调用可能要几毛钱。如果你的调用量很大，成本差异会非常明显。

我们的做法是，能用便宜模型解决的问题就不用贵的模型。对于简单的任务，比如分类、提取、简单生成，用小模型就够了。对于复杂的任务，比如深度推理、复杂创作，再用大模型。这样可以在保证效果的同时，把成本控制在合理范围内。

第三是延迟要求。不同的模型响应速度不一样。有的模型首字延迟很低，适合实时对话场景；有的模型虽然效果好但速度慢，适合离线处理场景。

如果你的应用是实时对话，用户在等着回复，那延迟就很重要，要选速度快的模型。如果是离线批量处理，延迟不敏感，就可以选效果好但速度慢的模型。

第四是稳定性和服务质量。大模型API的稳定性很重要，特别是对于生产环境的应用。有的模型服务经常超时、报错，或者限流很严重，用起来很痛苦。

我们在选择模型的时候，会先做一段时间的压力测试和稳定性测试，看看API的可用性、延迟分布、错误率等指标。稳定性不好的模型，即使效果再好，我们也不会在生产环境中使用。

第五是数据安全和合规。如果你的数据涉及敏感信息，那就要特别注意数据安全和合规问题。有的模型支持私有化部署，可以把数据完全控制在自己手里；有的模型是公有云API，数据会传到第三方服务器。

对于敏感数据场景，我们优先选择支持私有化部署的模型，或者有明确数据安全承诺的公有云服务。

综合考虑这些维度之后，我们通常不会只选一个模型，而是建立一个模型矩阵。不同的任务用不同的模型，甚至同一个任务也会有主模型和备用模型。这样既能保证效果，又能控制成本，还能提高系统的稳定性。

Prompt工程：好的Prompt是成功的一半

选好了模型，接下来就是Prompt工程。

很多人觉得大模型很智能，随便说句话就能得到想要的结果。但实际上，大模型的输出质量很大程度上取决于Prompt的质量。同样的模型，好的Prompt和差的Prompt，输出结果可能天差地别。

我们在Prompt工程上花了很多时间，总结了几个关键原则：

第一是明确角色和任务。在Prompt的开头，明确告诉模型它要扮演什么角色，要完成什么任务。比如"你是一个专业的客服代表，需要回答用户关于产品使用的问题"。这样模型就能进入对应的角色，用合适的语气和风格来回答。

不要只说"回答这个问题"，那样模型不知道该用什么角度和深度来回答。

第二是提供清晰的指令。把你想要模型做的事情，一步一步说清楚。比如"先阅读下面的文档，然后从文档中提取用户问题的答案，如果文档中没有答案，就说不知道，不要编造"。

指令越清晰，模型的输出就越符合预期。不要用模糊的表述，比如"帮我写个东西"，那样模型不知道你到底要什么。

第三是给出示例。对于复杂的任务，光有指令还不够，最好给出几个输入输出的示例。示例能让模型更准确地理解你想要的格式和风格。

比如你想让模型按特定的JSON格式输出，就给一个JSON示例。你想让模型用某种语气回答，就给一个回答示例。Few-shot learning是提高输出稳定性的有效方法。

第四是限制输出范围。大模型有时候会"话太多"，或者输出一些你不想要的内容。这时候你需要在Prompt中明确限制输出的范围。

比如"只回答用户的问题，不要添加额外的解释"、"输出不超过200字"、"只从提供的文档中找答案，不要使用外部知识"。这些限制能让输出更可控。

第五是处理边界情况。在实际应用中，用户的输入是千奇百怪的，很多时候不在你的预期之内。你需要在Prompt中考虑这些边界情况，告诉模型该怎么处理。

比如"如果用户的问题与产品无关，就礼貌地说明你只能回答产品相关的问题"、"如果信息不足，就说明需要哪些额外信息"、"如果用户有恶意意图，就拒绝回答"。

第六是迭代优化。Prompt不是一次就能写好的，需要不断地测试和优化。我们的做法是，先写一个初版Prompt，然后用一批测试数据来测试，看看哪些case效果不好，分析原因，然后修改Prompt，再测试。

这个过程可能要重复很多次，但每次优化都能让效果提升一些。最终的Prompt，往往是经过几十次迭代之后的结果。

除了这些基本原则，我们还会用一些进阶的Prompt技术，比如思维链（Chain of Thought）、自一致性（Self-Consistency）、思维树（Tree of Thoughts）等。这些技术能在复杂推理任务上显著提升效果，但也会增加延迟和成本，需要根据实际情况选择使用。

RAG：让大模型用上你的私有数据

大模型虽然强大，但它的知识是训练时的，有截止日期，而且不包含你的私有数据。在很多实际应用中，你需要让大模型使用你自己的数据，比如企业的文档、产品的说明、客户的历史记录等。

这时候就需要RAG（检索增强生成）技术。简单来说，RAG就是先从你的知识库中检索出相关的内容，然后把这些内容作为上下文传给大模型，让大模型基于这些内容来回答问题。

我们在多个项目中都用了RAG，总结了一些实践经验：

第一是文档切分。RAG的第一步是把文档切成小块，这样才能检索。切分的方式很重要，切得太大，检索不精准；切得太小，上下文不完整。

我们的经验是，根据文档的结构来切分，比如按段落、按章节、按语义块来切，而不是简单地按固定字数切。每个块的大小控制在500到1000字左右比较合适，同时块之间可以有一些重叠，避免上下文被截断。

第二是向量化和检索。切分之后，要把每个块转换成向量，存到向量数据库里。检索的时候，把用户的问题也转换成向量，然后在向量数据库中找最相似的几个块。

这里有几个细节需要注意。一是选择合适的embedding模型，不同的embedding模型效果差异很大，要选中文效果好的。二是检索的数量，一般取Top 3到Top 5，太少了信息不够，太多了会引入噪音，还会占用太多上下文。三是可以混合检索，比如向量检索加关键词检索，提高召回率。

第三是上下文组装。检索到相关的块之后，要把它们组装成Prompt的上下文，传给大模型。组装的时候要注意顺序，最相关的放在前面还是后面，对结果有影响。一般来说，把最相关的放在最后面，模型会更关注。

同时要给模型明确的指令，比如"请基于以下提供的文档内容来回答用户的问题，如果文档中没有相关信息，请回答不知道，不要编造"。

第四是处理检索不到的情况。有时候用户的问题在知识库中找不到答案，这时候模型可能会编造。要在Prompt中明确告诉模型，找不到答案的时候该怎么处理，比如"如果文档中没有相关信息，请如实告知，并建议用户联系人工客服"。

第五是持续优化知识库。RAG的效果很大程度上取决于知识库的质量。要定期检查知识库，更新过时的内容，删除无用的内容，补充缺失的内容。同时可以根据用户的反馈，优化文档的切分方式和检索策略。

RAG是一个看起来简单但做起来细节很多的技术。每一个环节都可能影响最终的效果，需要耐心地调试和优化。但做好了之后，它能让大模型真正用上你的私有数据，解决很多实际问题。

部署和优化：让大模型应用稳定高效地运行

把大模型应用做出来之后，接下来就是部署和优化了。

大模型应用和传统的应用不太一样，它有一些特殊的挑战，比如延迟高、成本高、输出不稳定等。要让大模型应用在生产环境中稳定高效地运行，需要做很多优化工作。

我们总结了几个关键的优化方向：

第一是缓存。大模型的调用是很贵的，也是很慢的。如果很多用户问的是相同或者相似的问题，完全可以把结果缓存起来，下次直接返回缓存的结果，不需要再调用大模型。

我们用了多层缓存机制。第一层是精确匹配缓存，如果用户的问题和之前的完全一样，直接返回之前的结果。第二层是语义缓存，把问题向量化，如果新问题和缓存中的问题相似度很高，就返回对应的结果。第三层是检索结果缓存，把RAG检索到的文档块缓存起来，避免重复检索。

缓存能大大降低调用次数和延迟，特别是对于FAQ类的场景，命中率能达到50%以上。

第二是异步处理。对于不需要实时响应的任务，比如批量生成、离线分析，可以用异步处理的方式。用户提交任务之后先返回一个任务ID，后台慢慢处理，处理完了再通知用户或者让用户来查询结果。

异步处理能削峰填谷，避免高峰期把大模型API打挂。同时也能更好地控制并发，避免超过API的限流。

第三是降级和容错。大模型API不是100%稳定的，偶尔会超时、报错或者限流。你的应用需要有降级和容错机制。

我们的做法是，每个模型调用都设置超时时间和重试次数。如果主模型调用失败，自动切换到备用模型。如果所有模型都不可用，就返回一个预设的兜底回复，比如"系统繁忙，请稍后再试"，而不是让应用崩溃。

同时要有监控和告警，实时监控API的调用量、成功率、延迟、成本等指标，出现异常及时告警。

第四是流式输出。对于对话类的应用，用户体验很重要。如果等大模型把整个回答都生成完了再显示，用户可能要等好几秒，会觉得很慢。

用流式输出的方式，大模型生成一个字就显示一个字，用户能看到回答在逐渐生成，体验会好很多。虽然总时间没有减少，但感知上会快很多。

第五是并发控制。大模型API通常都有限流，比如每分钟最多调用多少次，每秒最多多少并发。如果你的应用流量很大，需要做好并发控制，不要超过API的限制。

我们用了令牌桶算法来控制调用速率，同时维护了一个请求队列，超过限流的请求排队等待。这样既能充分利用API的配额，又不会因为超限而被拒绝。

第六是模型路由。对于复杂的应用，可能会用到多个模型。可以做一个模型路由层，根据任务的类型、复杂度、成本要求等因素，自动选择最合适的模型。

比如简单的分类任务路由到小模型，复杂的推理任务路由到大模型，中文任务路由到中文能力强的模型，代码任务路由到代码能力强的模型。模型路由能在保证效果的同时，优化成本和延迟。

这些优化措施，我们都是在实际应用中逐步加上去的。刚开始的时候应用很简单，就是直接调用API。后来随着用户量增长，各种问题都出来了，我们就一个一个地解决，最终形成了一套比较完善的部署和优化体系。

成本控制：大模型不是越用越贵

大模型用起来很爽，但账单出来的时候可能会心疼。特别是调用量大的时候，成本可能会很高。

我们在成本控制上做了很多工作，总结了几个有效的方法：

第一是模型分级。前面说过，不同的任务用不同的模型。简单任务用便宜的小模型，复杂任务才用贵的大模型。这是最有效的成本控制手段，做好了能省一半以上的钱。

第二是缓存。前面也说过，缓存能减少重复调用。对于重复性高的场景，缓存的成本节省效果非常明显。

第三是优化Prompt。Prompt越长，消耗的token越多，成本越高。要尽量精简Prompt，去掉不必要的内容。同时可以优化上下文的长度，比如RAG只取最相关的3个块，而不是5个或10个。

第四是限制输出长度。在Prompt中限制输出的最大长度，避免模型输出过长的内容。比如"回答不超过200字"，这样能减少输出token的消耗。

第五是批量处理。对于离线任务，可以把多个请求合并成一个batch来处理，提高效率，降低成本。很多大模型API都支持批量调用，价格也更便宜。

第六是监控和预算。要实时监控成本，设置预算告警。当花费超过阈值的时候，及时告警，避免超支。同时定期分析成本结构，看看哪些任务花的钱最多，有没有优化的空间。

通过这些方法，我们把大模型的使用成本控制在了一个比较合理的范围内。虽然调用量在不断增长，但总成本的增长速度比调用量的增长速度慢很多。

评估和迭代：持续优化效果

大模型应用不是上线就完事了，需要持续地评估和迭代。

大模型的输出有不确定性，同样的输入可能会得到不同的输出。而且用户的需求也在不断变化，模型本身也在更新。所以需要建立一套评估和迭代的机制，持续优化应用的效果。

我们的做法是：

第一是建立测试集。收集一批有代表性的测试用例，覆盖各种常见场景和边界情况。每个测试用例都有标准的答案或者评分标准。每次修改Prompt或者更换模型之后，都用测试集来跑一遍，看看效果有没有提升或者下降。

第二是人工抽检。自动化测试不能覆盖所有情况，还需要人工抽检。定期抽取一部分真实的用户对话，人工评估回答的质量，包括准确性、相关性、流畅性、安全性等维度。

第三是用户反馈。在应用中加入反馈机制，让用户可以对回答点赞或者点踩。收集用户的反馈，特别是负面反馈，分析原因，然后优化。

第四是bad case分析。对于效果不好的case，要深入分析原因。是Prompt写得不好？是检索不到相关内容？是模型能力不够？还是用户的问题本身有问题？找到原因之后，针对性地优化。

第五是持续迭代。根据评估和反馈的结果，持续优化Prompt、知识库、模型选择、系统逻辑等。大模型应用的优化是一个长期的过程，没有最好，只有更好。

通过这套评估和迭代机制，我们的应用效果在不断提升。刚上线的时候可能只有70分，经过几个月的迭代，能达到90分以上。

写在最后

国产大模型的发展速度超出了很多人的预期。两年前我们还在担心国产模型能不能用，现在已经在考虑怎么用得更好、更省、更稳了。

这篇文章总结的是我们团队在实际项目中积累的一些经验。模型选择、Prompt工程、RAG、部署优化、成本控制、评估迭代，这几个方面构成了我们使用国产大模型的最佳实践体系。

当然这些经验不是标准答案，每个团队、每个项目都有自己的特点。重要的是在实践中不断摸索，找到最适合自己的方法。

大模型技术还在快速发展，新的模型、新的技术、新的应用场景不断涌现。我们也在不断学习和适应，更新自己的最佳实践。

最后想说的是，大模型是一个强大的工具，但它不是银弹。要真正发挥它的价值，需要深入理解它的能力和局限，结合具体的业务场景，精心设计和持续优化。只有这样，才能让大模型真正为你的业务创造价值。

愿我们都能在大模型的浪潮中，找到属于自己的最佳实践。