稳步前行运维学习者

我也踩过这个坑，一开始把MCP的prompt当成系统提示词来写，塞了一堆角色设定和规则，结果上下文被吃掉一大半，模型反应还变迟钝了。后来发现MCP里prompt更像个“参数化模板”，核心是把变量和场景逻辑拆开，固定的规则能塞进工具描述或资源里就别硬写进prompt。我现在习惯只留几个关键占位符，剩下的让工具按需拉取，上下文清爽很多，模型也灵活了。你说的“程序化”方向我觉得是对的，但也不用走极端，场

试试按文档结构切分再给每个chunk带上父级标题，检索后拼装时能自动补上下文。

学到了，感谢分享！

学到了，感谢分享！

刚入门，这个对我帮助很大。

学到了，感谢分享！

写得挺好，建议补充一些性能数据。

这个思路不错，收藏了。

512固定切块对产品手册这种结构文档确实容易把退货流程和报价条款切到一起，语义就串了。你可以先试试按标题层级切，再用语义相似度合并相邻段落，比纯字符切靠谱不少。重排模型该上还是得上，bge-reranker对你这场景提升会很明显。至于意图分类，FAQ量不大的话不如直接关键词路由来得快。

加个rerank确实有用，我用的bge-reranker，top_k降到3效果反而更好。

训练时确实该混点变体prompt，不然模型只认死模板。历史对话也建议拼进去，不然后面多轮真的会断片。

Kimi这价格确实狠，不过我倒好奇它长期推理成本真能压这么低，还是烧钱抢市场？

你gpu_memory_utilization设0.9其实挺激进的，两张卡各占90%本来就容易一叠加就崩。我之前跑7B int4也遇到过类似情况，后来把max_num_seqs降到32、gpu_memory_utilization调到0.85就稳多了。vllm那个动态管理主要管KV cache，长文本多并发下cache膨胀很快，不是真的能无限回收。建议你先把并发压下来试试，另外看看是不是有请求一直

工具定义还是放System里稳，User层只留任务指令，多轮容易飘就加个工具schema摘要每轮重述。

我之前也踩过这坑，后来发现光调chunk size没用，得先看你的检索器是啥。用向量检索的话，1024反而容易把语义拉散，256又太碎，我最后在512上下浮动效果最稳。overlap我一般设50-100，主要看段落边界，Markdown可以按标题切，别硬切。代码块和正文最好分开处理，代码块保持完整别切开，不然检索出来全是半截函数。

多文档一长确实容易这样，GPT-4对中间位置的文档注意力会衰减，你塞3000字它基本就挑着看了。我试过把检索片段按相关度重排、每个片段前面加编号和来源，让它引用时带上编号，幻觉能压下去不少。不过说到底prompt只是缓解，真要做稳还是得靠重排模型先把top5筛成top2，再配合微调或者用小模型做路由。你现在的拆分逻辑可能没问题，是信息密度太高把它淹了。

10万切片单机Qdrant完全够用，部署也省心，LangChain接入基本没区别。

8G显存跑13B确实得靠CPU帮忙扛一部分，llama.cpp的Q4_K_M量化加部分层offload到内存，13B大概能跑但速度就看你CPU和内存带宽了。我之前用3060 12G试过13B的q4，全放显存也就十几token每秒，你8G的话建议把30层左右丢给CPU，剩下的放显卡，速度大概能到5-8token每秒，写代码等半分钟其实也还行。另外可以试试exllamav2的量化，它显存利用比llam

价格战是好事，但别急着吹，等K3真实跑分和稳定性出来再说。

我之前也遇到过类似问题，后来换了方案。