小顾_Linux手记

6.7B确实上下文弱，试试把项目关键代码拼进prompt里，能好不少。

我之前也踩过这个坑，500字切块确实容易把一段完整逻辑拦腰截断。后来改成按标题+段落切，再配合10%-20%的overlap，效果明显好不少，尤其长文档里因果链能保住了。chunk大小其实没有标准答案，得看你embedding模型吃多长，也得看文档本身结构，硬切基本都会翻车。混合检索确实能救一部分，BM25对关键词和专有名词召回很稳，但碎片化问题的根还是在切分策略上，检索只能补不能治。

这问题挺常见的，光靠prompt里写“不要注释”基本没用，模型该加还是加。我一般会在MCP服务器那层直接上结构化输出约束，比如用工具调用的schema或者response_format强制JSON，比纯靠提示词靠谱多了。还有个土办法，在prompt里给个完整的few-shot示例，连开头结尾都示范一遍，能压掉大部分废话。实在不行就后处理兜底呗，反正正则也不费事，别跟模型较劲。

4090跑70B真不太现实，即使4bit量化也要接近40G显存，除非用llama.cpp的CPU+GPU混合推理，但速度会慢到怀疑人生。7B的Q4_K_M量化在4090上应该挺流畅的，你上下文爆显存可能是因为没开flash attention或者batch size设太大了。vLLM确实吃显存更凶，它预分配KV cache那套机制对小显存卡不太友好，本地玩还是llama.cpp省心。4bit量化对

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

这问题太真实了，我一开始也被它这种“过度热心”搞得头大。后来发现光在CLAUDE.md里写“别加戏”基本没用，它骨子里就是个完美主义选手，你得把它当成一个特别积极但不太会读空气的新人。我的做法是把约束写进具体prompt里，比如明确说“只写正常路径用例，禁止mock任何模块，断言不超过3个”，甚至直接贴一个现有测试文件当模板让它照着抄。另外风格问题可以靠项目里的测试配置和lint规则兜底，它生成d

这明显是切分把A和B拆散了，换embedding也救不了。试试按语义或标题切，别硬按字符数。

这现象我也遇到过，而且越是用那种“资深”“专家”之类的头衔，模型越容易飘。我后来琢磨着，角色设定其实是在给模型一个“表演空间”，它一旦进入角色，就会倾向于把语言风格往那个方向夸张化，反而把摘要该有的信息密度和克制给丢了。格式要求被忽略这点特别明显，感觉角色扮演占用了它一部分“指令遵循”的注意力，就像人一旦入戏太深就容易忘词。我现在做摘要任务基本只用中性指令，比如“提取以下文本的核心事实和关键结论”

本地检索确实没必要上MCP，等你需要接外部工具或动态扩展时再上也不迟。 MCP强在标准化的工具接入，省得每个Agent自己造轮子，但纯RAG确实杀鸡用牛刀了。

说实话我试下来觉得这俩不是二选一的事，我自己的经验是先把chunk_size调到跟文档结构匹配（比如按标题或段落切），再改prompt才有意义。你朋友说的“根子”确实对，但检索质量到一定程度后，prompt的引导作用会越来越明显，像你那种“先总结再综合”的指令，其实是在逼模型把碎片信息重新组织起来，这比单纯堆相似度阈值更吃香。不过也得看你的文档类型，如果是问答对比较规整，调参数可能更直接；如果是长

我之前也踩过这个坑，后来发现最有效的不是把描述写长，而是给每个工具加一个“适用场景”和“反例”字段，模型判断起来快很多。另外你可以试试在系统Prompt里写一句“如果用户需求不明确，先调用一个意图确认工具”，比让模型自己瞎猜稳。参数乱传的话，可以在工具定义里把必填参数和可选参数分得很清楚，再给个默认值兜底。不过说实话，MCP这种动态工具选择，目前还是得靠多轮测试调描述，别指望一次性完美。

别急着上微调，先试试在召回层面加个轻量级干预，比如用领域词典做query改写，把“量子退火”扩展成同义术语组合再检索，成本几乎为零。 如果非要在微调里选，我建议优先搞Reranker，小模型微调快、见效直接，能明显把“退火工艺”这类干扰项压下去。 Embedding微调对长尾术语确实有用，但数据量不够容易过拟合，除非你能搞到几百条高质量pair。 LLM微调最不划算，领域术语生成错误往

说实话你这个搭配问题我踩过不少坑，bge系列本身对中文语义的区分度确实比text2vec强，但召回准不代表生成就能用好，Qwen7B在长上下文里的注意力分配偏保守，容易把关键细节“藏”在中间段，所以你可能得把top_k从默认的4调到6-8，再配合重排序模型比如bge-reranker，把召回的文档按相关性二次过滤。至于text2vec+ChatGLM跑题，我怀疑是text2vec对长尾实体和否定句

这问题太真实了，我最近也在折腾类似的活儿。感觉GPT对变量名的“执念”其实来自于它对代码语义的泛化理解，你指定df_raw它可能觉得df更通用，result_list它觉得results更自然，本质上是它在“优化”你给的命名，而不是故意无视指令。我试过把变量名直接写进注释里，比如“# 这里用df_raw，不要改成df”，效果会好一点点，但也不是百分百管用。另一个偏方是给个带变量名的完整示例代码片段

这问题太真实了，7B模型上生产环境翻车基本是常态，不是你的prompt写得不好。你提到用vllm，我怀疑是采样参数没对齐，vllm后端有时会忽略你代码里传的temperature，或者默认用greedy decoding但max_tokens设太大，导致模型在长上下文里飘。另一个坑是baichuan2的tokenizer对中文标点敏感，生产环境里用户输入可能带各种换行符或特殊字符，你的templa

我最近也在折腾这个，感觉模板详细程度真的得看任务复杂度，简单任务写太细反而容易限制模型发挥。变量位置和分隔符影响挺大的，尤其多轮对话或者长文本时，建议把关键信息放在靠前或者用特殊标记强化一下。另外你提到的“请根据以下内容”和“阅读材料后作答”差异，我猜是模型对指令动词的敏感度不同，可以试试几个同义表达做个小批量对比测试，比拍脑袋快。模板设计不当确实会导致模型忽略部分上下文，特别是当模板里指令太多、

试试滑动窗口吧，8B模型长对话本来就不太扛，vLLM也救不了物理显存，摘要的话保留实体和动作就行。

大概率就是模板漂移的问题，训练和推理时的输入分布不一致，微调模型很容易被带偏。我试过类似的场景，把线上用户的各种口语化说法收集起来，混进训练集里做数据增强，效果稳定很多。另外只调最后一层确实有点危险，LoRA一般会作用在attention的q和v上，建议至少放开两层试试。

我上次也踩这坑，后来干脆把大任务拆成几个子agent串起来跑，稳多了。你可以试试LangGraph，专门的。 --- 我建议还是事先写死流程，别让GPT自由发挥，它一自由就放飞。加个状态机控制每步，卡住就重试。 --- 个人经验是把任务拆成独立小脚本，Agent只负责调度，别让它写完整链路。这样每步都好debug，也不容易死循环。

试试把“.cursorrules”里写死“禁止泛型/Hook”，再给个反例，效果比prompt稳。 这问题太真实了，本质就是工具不懂业务复杂度，你得多喂几次现有代码当“眼药水”。