嗨，我这几周一直在尝试制作一个对话代理，但成果不太令我满意。我使用的是RTX 4070，我发现它能让我非常流畅地运行参数量在70 - 80亿（7/8B params）左右的模型，基本上所有占用<8GB显存（VRAM）的模型都能轻松运行。说实话，这么小的模型能有这样的输出质量让我很惊讶，但它们理解指令方面存在问题。由于这些模型很小，我尽量避免使用太长的系统提示词（system prompts），我的提示词一直在400字左右。我试过长短不同的提示词，也试过各种模型，但它们都容易陷入常见的陷阱：1. 生成很长的回复，忽略我要求保持1 - 2句话的指令；2. 生成典型的大型语言模型（LLM）回复，每个回复末尾都有开放式问题，如‘你对X有何看法？’；3. 有时会奇怪地卡在宽泛地重复谈论一个通用话题上，而不遵循对话的流程。这些问题很抽象，很难探究。不过最大的痛点是，无论我在提示词中做什么来缓解这些问题，似乎大多都被忽略了。我知道这些是小模型或旧模型的常见陷阱。我有一些进一步探索的想法，比如：1. 也许尝试写一个很长的提示词，准确解释什么是对话；2. 也许我应该尝试给它更多示例，例如硬编码一个对话的开头；3. 也许我应该尝试自己进行微调（虽然我不太擅长复杂的技术内容）。我特别在想，也许所有模型要么是针对企业资源规划（ERP）进行了微调，要么是针对聊天机器人的查询/回答进行了微调，而我可能还没有找到一个能进行友好的、适合大众观看（SFW）对话的好模型；4. 我也在试验向系统输入多少元数据以及如何输入（例如，对话主题是X，到目前为止的对话内容是XYZ……）。我之前是将这些作为系统消息（SystemMessage）插入到对话流中来完成对话的，但也许这样不好，我不太确定。我想知道这些内容放在系统提示词里好还是放在讨论线程里好；5. 也许我可以让一个小模型再进行一轮处理，将我的模型的输出缩短，使其适合对话。但在我继续在这上面投入大量时间之前，我想从可能更懂的人那里收集反馈，因为也许我只是遇到了瓶颈，除了投资更好的硬件之外我做什么都无济于事。话虽如此，如果我花很多钱增加一点显存，而130亿（13b）或更大的模型仍然无法遵循简单指令的话，我会很懊恼的。你们怎么看？我已经阅读了我能找到的关于小模型陷阱的所有资料，但我还没有找到诸如以下问题的答案：有人知道对于一个70亿（7B）模型，我的系统提示词最长能写多长吗？我的缓解计划中有没有哪个看起来比其他的更有希望？在对话式人工智能方面我是否遗漏了什么技巧？谢谢。附言：我用neuraldaredevil - 8b - abliterated:q8_0、l3 - 8b - stheno - v3.2或者mn - 12b - mag - mell - r1:latest、deepseek - r1:8b取得的结果最好，deepseek - r1:8b不错，但我无法让它生成简短的答案。
讨论总结
原帖作者在使用较小模型（<10GB）构建对话代理时遇到了诸如模型难以理解指令、产生大篇幅回应、陷入常见错误等问题，正在寻求专家意见。评论者们针对这些问题展开了讨论，给出了不同的建议，包括推荐不同的模型（如phi - 4 14B、Mistral Nemo等），提出不同的优化方法（如少样本学习、调整上下文长度、改变提示方式等），还分享了自己对于不同规模模型性能的看法，如32b是模型开始变好的起点、70b才达到“相当好”的水平等。整个讨论氛围比较积极，大家都在努力为原帖作者出谋划策。
主要观点
- 👍 32b是模型开始变好的起点
- 支持理由：在这个规模下模型性能有提升，如在处理一般对话时表现较好。
- 反对声音：有人提到Mistral small 3 24b虽小于32b但表现不错。
- 🔥 小模型存在局限性，性能会随上下文增加而下降
- 正方观点：原帖作者在使用小模型构建对话代理时遇到的指令理解困难等问题就是小模型局限性的体现。
- 反方观点：有人认为小模型在特定任务中表现不错，并非在所有情况下都有局限性。
- 💡 模型训练方式比规模更重要
- 解释：如果训练不当，即使是大模型结果也不理想，原帖作者使用的模型类型导致长回复就是因为模型训练可能不符合需求。
- 💡 8 - 14B模型（Q4/Q5）在长指令列表下遵循指令能力较差
- 解释：评论者根据自己的尝试得出这一结论。
- 💡 70B模型在指令遵循等方面表现出色
- 解释：70B模型能够理解长提示中的所有要求，每秒处理约1个事务。
金句与有趣评论
- “😂 我认为32b是模型开始变好的起点，但我肯定这里有一百万人会不同意。”
- 亮点：表达了一种虽然有自己的观点，但也知道这个观点可能存在争议的态度。
- “🤔 Mistral small 3 24b是相当令人印象深刻的<32b模型，它是我目前的首选。”
- 亮点：提供了一个小于32b但表现不错的模型例子。
- “👀 我觉得直到70b才达到“相当好”的级别。”
- 亮点：明确给出了对70b模型性能的评价。
- “😎 我的一个应用是一个谈论特定主题的对话机器人。它可以从关于该主题的RAG系统中提取数据。在这种情况下，即使是8 - 14B的模型似乎也不错。”
- 亮点：通过实例说明小模型在特定应用中的可行性。
- “🤨 你正面临着小模型的局限性以及随着上下文增长而出现的性能普遍下降的情况。”
- 亮点：直接点明原帖作者遇到问题的根源。
情感分析
总体情感倾向是积极的，大家都在积极为原帖作者提供建议和分享经验。主要分歧点在于对不同规模模型性能的看法，例如32b是否是模型变好的起点，小模型是否存在不可避免的局限性等。可能的原因是大家使用模型的场景、经验以及对模型性能评判的标准不同。
趋势与预测
- 新兴话题：模型训练方式对模型性能的影响可能会引发后续讨论，还有如何更好地优化小模型以解决指令理解等问题。
- 潜在影响：对于对话代理的开发以及模型的优化使用有一定的指导意义，可能促使更多人关注模型训练方式的重要性，也可能让开发者在选择模型时更加谨慎，综合考虑模型规模和训练方式等因素。
详细内容：
标题：关于小型模型的性能与限制的热门讨论
在 Reddit 上，一篇题为“Expert opinion requested: Am I reaching the limits of <10GB models?”的帖子引发了众多关注。该帖子的作者表示，自己尝试制作对话代理数周，但对成果不太满意。作者使用 RTX 4070 运行 7/8B 参数的模型较为顺畅，但这些小模型在理解指令方面存在困难。尽管作者努力避免过长的系统提示并将其控制在 400 字左右，但模型仍存在诸多问题，如无视指令生成冗长回答、产生刻板的 LLM 式回应等。
此帖获得了大量的评论和讨论。有人认为 32B 以上的模型才开始表现出色，也有人称赞 Mistral small 3 24b 在小于 32B 的模型中表现不错。还有用户指出 30B 左右的模型适用性更广，70B 以上的模型才算“好”。
一些用户给出了具体的建议，比如尝试 4 位量化的 phi-4 14B 模型，认为其在遵循指令方面表现良好；有人建议对基础模型进行少样本学习，使用 5 到 10 个示例对话来展示期望的行为；有人推荐 phi-4 模型，称其非常好用；也有人认为应该根据具体需求重新评估模型，先让基础模型满足需求，再寻找具有特定写作风格和目的的微调模型。
同时，也有不同的声音。有人表示自己所面临的问题并非小型模型所独有，模型的训练方式比大小更重要；还有人认为应精简提示，将任务分解为多个提取步骤和最终的回答步骤，并利用常见前缀缓存来减少模型的加载时间。
讨论的核心问题在于如何在有限的硬件条件下，让模型更好地理解指令并进行有效的对话，以及不同规模的模型在性能和适用性上的差异。
在这场热烈的讨论中，各方观点精彩纷呈。有人坚信大型模型的优势，有人则认为小型模型在特定任务中也能出色发挥。究竟如何在模型规模和性能之间找到最佳平衡，还需要进一步的探索和实践。
感谢您的耐心阅读！来选个表情，或者留个评论吧！