周末后端札记

榜单数据确实只能参考，实际效果跟你的文档类型、切分方式、查询写法关系太大了。bge-large-zh在中文上理论上是强，但它对query和passage的指令前缀比较敏感，你检索的时候有没有给query加对前缀？不加的话效果会差一截，这个坑很多人踩过。openai的3-small胜在稳定和语义泛化好，尤其长query和口语化提问，但成本跟数据合规确实是硬伤。chunk设500对中文长文档偏小了，试

我一般按项目拆.mcp.json，只开当前要用的，用完就关，响应快不少。

我遇到过类似情况，后来在向量检索后面加了一层cross-encoder重排，效果挺明显的。具体做法是先粗召回top 20，再用小模型对query和每个片段算相关性打分，取前3-5个喂给LLM。另外文档切分别按固定长度硬切，尽量按段落或章节语义边界来分，不然功耗参数经常和散热描述混在同一块里。

只需要对用户的问题做一次embedding就行了，文档库的向量是提前算好存进去的，检索时拿问题的向量去比对，不会重新embedding整个库。真正要操心的是文档更新那块，新文档或者改动过的得单独重新embedding再塞回库里，不然检索结果会过时。我之前也卡在这个点上，后来发现建索引那步才是最花时间的，查询本身很轻量。

几千条数据训10个epoch确实容易过拟合，loss不降可能是数据质量或格式问题，建议先拿几百条测过拟合。

Ollama长上下文确实拉胯，换回vLLM或llama.cpp会好很多。试试在系统提示里加一句“只补全当前函数相关代码”，能少很多乱联想。

入门直接Chroma吧，轻量够用，等真跑起来了再换也不迟。

口语化query和文档书面语的语义gap确实容易被忽略，BGE-large换了也没用说明问题可能不在模型本身。建议先别急着调chunk，把线上真实query捞一批出来，人工标注下哪些该召回哪些不该，跑个recall@k看看baseline到底多差。chunk按固定字数切确实容易把条文腰斩，试试按标题层级或语义段落切，配合overlap能救回不少。另外加个rerank（比如bge-reranker）

800 token 其实不算长，但问题可能出在信息密度上。你塞了一堆规则进去，模型反而抓不住重点，尤其是 MCP 这种工具调用场景，指令优先级比上下文长度更关键。我自己的做法是把硬性规则放最前面，用简短编号列出来，背景信息挪到后面或者干脆让模型按需拉取。拆成多步调用确实更稳，比如先让它识别问题类型，再针对性地给审查意见，比一次性喂一大坨效果好很多。

我一般只把纯用户问题存进向量库，Prompt模板和系统指令单独放，检索时再动态拼回去。你遇到的那种带用户ID的上下文，混进去确实容易让相似度失真，还不如在metadata里打个用户标签过滤。text-embedding-ada-002是1536维，直接用默认就行，没必要改。真要优化，不如先做一轮query改写再检索，比纠结维度有用多了。

CodeLlama就这毛病，试试在prompt里加句“只输出代码，不要注释”，能压住不少。

这个问题我也踩过坑，Cursor确实有这个毛病，尤其是你项目里如果存在一些不规范的老代码，它会学坏。光在prompt里写“遵守React规则”太抽象了，它理解不了那么细。我的经验是在.cursorrules文件里加几条硬性约束，比如“所有hooks必须在组件函数顶部声明，禁止在JSX表达式或回调内定义hook”，这种具体指令比泛泛而谈管用得多。另外你说的eslint联动，可以在项目根目录配好esl

这个其实很常见，GPT-4对格式的“洁癖”确实靠一句“不要输出多余内容”压不住。我一般会在Prompt最后加一句“只返回纯SQL字符串，不要任何解释、注释、markdown标记”，并且用分隔符把示例和指令隔开，效果会稳很多。few-shot确实有用，但示例里千万别带反引号或代码块，不然模型会跟着学。另外可以考虑用function calling或JSON mode来约束输出，比纯靠Prompt硬掰

500条数据确实太少了，LoRA在这种规模下很难学到有效映射。建议先拿公开的客服数据集试试，排除数据本身的问题。

ZeRO-3 offload参数要配`cpu_offload`加`pin_memory`，另外试试`stage3_gather_16bit_weights_on_model_save`，我上次就是这么救回来的。

建议保留，微调只是让模型适应风格，但推理时不带前缀它还是会随机漂移，带上一模一样的更稳。 我试过把系统提示词改成更短的版本，效果比完全去掉好，但跟训练时完全一致还是最靠谱。

试试把表格单独抽出来建索引，正文按条款编号切，别按标题切，效果会好很多。

数据混合比例的问题确实存在，5000条内部评审记录对7B模型来说占比太高了，很容易把通用知识冲掉。我建议你把领域数据控制在10%-15%，同时保留一部分原始通用语料做联合训练。另外，工具触发的误判可能跟MCP的system prompt里工具描述太宽泛有关，试着把每个工具的触发条件写得再严格些，比如明确加上“仅当代码存在明确安全风险时才调用”。你还可以试试在微调时加入一些负样本，专门标注哪些场景不

说实话，你提到的self-debug循环这点我特别有共鸣，之前拿GPT Agent跑一个带登录态的爬虫脚本，它总是在cookie失效后直接摆烂，得我手动把整个session逻辑塞回去，而Agent 2.0确实会自己打印异常然后尝试改header或者重试，这点体验差距是实打实的。但关于那27%的提升，我有点怀疑是不是benchmark里混合了太多代码生成类任务，毕竟这类任务本身就有标准答案，模型好模

这问题我当初也踩过类似的坑，7B在双卡上跑DDP，通信开销和计算量不成比例，尤其4090这种卡间互联走PCIe的，带宽瓶颈比想象中严重得多。你单卡batch1.2秒，说明计算密度已经很高了，这时候梯度同步的延迟反而成了主导，多卡不划算很正常。建议先看看你是不是没开cudnn.benchmark或者没设torch.backends.cuda.matmul.fp16_allow_reduced_pre