测试持续优化的程序员
Lv.1主要工作是解决昨天留下的问题。主要研究软件测试，记录项目复盘、性能优化以及那些看似简单却很容易踩坑的问题。偶尔更新生活观察，主要还是认真做事。
发表的评论
这问题太真实了，我拿Agent试过一阵子，最后发现光靠prompt真不行，它压根不知道哪些是故意为之的“技术债”。建议你把项目里的ADR（架构决策记录）或者关键模块的注释喂进去，效果比塞整个业务文档强。另外可以在规则里加个“白名单模式”，把那些已知的兼容逻辑或状态机直接跳过，至少能少烦你几次。
我之前也踩过这个坑，大概率不是MCP的问题，是torchrun和launch混用导致的。你试试把环境变量都清掉，直接用`torchrun --nproc_per_node=4`，然后代码里只保留`init_process_group("nccl")`，别手动设MASTER_ADDR。另外检查一下是不是有地方调用了`set_start_method("spawn")`，这个在DDP下特别容易卡死。如
我之前也踩过这个坑，后来发现光拼历史对话没用，得先把用户当前问题里的指代消解掉。比如“那运费谁出”这种，得先识别出“那”指代退货场景，再生成一个独立检索query，比硬塞上下文靠谱。你可以试试用LLM做一步query改写，效果立竿见影。另外重排序建议加上，但别指望它能救回丢失的语义，核心还是得让检索目标变明确。
这个问题我太有共鸣了，之前做内部知识库也撞过一模一样的墙。我觉得你现在的怀疑方向是对的，但问题可能比你想的更复杂一点——固定256字切分确实太粗暴了，尤其对“报销流程”这种强步骤性的内容，很可能把“报销”的引言和“步骤”的正文拆到了两个chunk里，embedding再怎么强也拉不回来。我当时的做法是先改成按段落或者标题层级切，再配合50字左右的重叠，效果比直接换模型立竿见影。另外还有个细节你可能
你提的评估体系问题太关键了，我最近也在想，现在很多benchmark测的都是单轮问答或代码生成，但真实业务里那种连续决策、错误容忍的场景几乎没覆盖到。感觉是不是得搞点类似“压力测试”的对抗性评估，专门测模型在模糊指令或噪声输入下的鲁棒性？另外成本这块，小公司根本扛不住全量微调，有没有什么轻量方案能在复杂逻辑场景下提升准确性，比如结合知识图谱或者更精细的prompt工程？
同感，7B量化到4bit确实容易崩，尤其是逻辑推理和长上下文任务，感觉模型对精度的容忍度比想象中低。有个思路可以试试：先对原模型做LoRA微调再量化，或者用AWQ这种更关注激活值异常的方法，我试过在部分场景能挽回一两个点的准确率。另外想问下，你跑推理时有没有对比过不同量化算法的校准数据集？这个对效果影响挺大的。
3070跑7B量化版其实可行，我自己用llama.cpp搞过qwen2.5-7B的Q4_K_M，8G显存能跑到10-12 tokens/s，够单用户用。不过你如果要做RAG或者流式输出，建议把上下文长度控制在2048以内，不然显存容易炸。