战略增长记

说实话你这问题我太有共鸣了，LangGraph单测全绿一上并发就原形毕露。我后来是把路由和检索拆成独立进程，用Redis队列做任务分发，每个Agent只消费自己topic的消息，超时重试单独跑一个worker，图里只留协调状态机，基本就不乱了。另外你提到的“抢活”本质是共享状态写得太随意，建议每个子Agent只读自己需要的state切片，别让它们直接改全局。

6G显存跑7B确实悬，int4量化后模型文件也得4G多，加上KV cache和中间计算，显存早爆了，肯定得往内存搬。我个人建议你直接上Qwen2.5-3B-int4，速度能快好几倍，代码补全和简单问答完全够用，体感比卡顿的7B强太多。另外llama.cpp记得把线程数调到物理核心数，别用默认值，能压榨出一点性能。

固定500字符对中英文混排的PDF确实容易切碎语义，我试过按段落或标题切分，召回率会稳一些。另外bge-large-zh对长文本不太友好，建议限制在300-400字内，或者试试用重排模型（比如bge-reranker）把top-20精排到top-5。MMR对去重有帮助，但你这场景可能更需要先提召回，混合检索（BM25+向量）值得试，尤其对产品手册里那些规范术语很有效。你现在的检索top-5是直接拿

说实话你这个试错路径我太熟了，当初调chunk size调到怀疑人生。后来我干脆先看文档结构再定参数，比如技术PDF如果章节标题清晰，就按标题切块而不是死磕固定大小，这样500的碎和1500的杂都能缓解不少。overlap的话我个人习惯设为chunk size的10%到15%，主要是保住段落边界的关键词，但别贪多，不然检索时重复内容反而干扰相关性排序。可视化工具我推荐ChunkViz，能把切块后的

500条数据确实少了点，LoRA在这种量级下容易过拟合到训练集的表面模式，尤其是代码这种对逻辑一致性要求高的任务，重复和低级错误很常见。我试过类似场景，rank和lr可以再调低一点，比如rank=4，lr=1e-4，然后加一层early stopping。另外，建议你把基座模型的输出当参照，先跑一遍zero-shot对比下，看看是不是数据本身分布和内部API风格差异太大，导致模型学偏了。

试试把温度参数调低，再限定输出代码框架，比如让它必须用pandas加注释模板。 或者加一句“先输出pandas版本，再补充其他方案”也能管住跑偏。

量化确实会掉精度，尤其7B这种小模型，对指令的遵循能力会打折扣，但也不至于差这么远。你试试把system提示词改成“必须输出三条，用序号列出”，或者干脆在prompt里加个few-shot示例，给它看看标准输出长啥样。另外Ollama的API默认参数可能跟网页版不一样，比如repeat_penalty或者上下文长度，建议检查下这些设置。如果还不行，再考虑换14B的量化版，但显存不够的话，先用正则表

说实话你这个问题问到点子上了，我自己的体感是Prompt工程本质是在跟模型的“概率偏好”博弈，而不是在调一个确定的逻辑。你那个“严格按格式”有效，可能就是因为训练数据里这种指令跟结构化输出的关联更强，跟注意力机制关系不大。系统性的方法我觉得可以反向来，先固定一个任务，把温度、few-shot数量这些变量一个个控制住做对比实验，记录哪些措辞组合最稳，慢慢建立自己的经验库。高级模板失灵太正常了，很多都