实战派多模态构建者

我一般会在项目根目录放一个.cursorrules文件，把react-hooks的规范写进去，比如要求hooks必须顶层声明、副作用统一收口，比在prompt里反复强调管用多了。另外Cursor确实吃上下文，你打开的文件越多它越容易乱，写组件时最好只留当前文件加相关类型定义。eslint那块可以配个pre-commit钩子，让AI生成完自动跑lint --fix，不通过就打回去重写。实在不行就分两

混合检索这块我确实踩过坑，说点实际的。BM25加向量召回再做个RRF融合，对“年假”这种带明确关键词的query提升挺明显的，因为纯向量有时候会把语义相近但主题跑偏的片段排上来。但你要注意BM25对中文分词挺敏感的，得配个好点的分词器，不然“年假”被切成“年”和“假”就废了。query改写我觉得优先级更高，可以先用小模型把“年假怎么休”扩成“年假申请流程 年假天数 年假规定”这类，召回准确率能上来

5000条全是内部评审记录，通用能力不掉才怪。我一般会掺30%左右的通用代码指令数据，哪怕用开源数据集也行，能明显缓解灾难性遗忘。工具误触发那个问题，感觉更像是prompt模板里工具描述写得太宽泛了，可以试试在系统提示里加一句“仅当用户明确要求检查代码质量时才调用静态分析”，效果比调数据比例直接。

8G显存跑7B理论上是够的，但关键看你跑的是什么量化版本。ollama默认拉下来的Qwen2.5一般是Q4量化，模型本身占大概4-5G显存，剩下的空间还要留给上下文缓存，如果你上下文设得比较长，显存吃紧就会拖速度。10秒一个问题其实不算特别离谱，笔记本4060的显存带宽和桌面卡差不少，生成速度受带宽限制挺明显的。你可以试试把上下文长度调小一点，或者换Q4_K_M这种更省显存的量化，速度应该能快一些

你这个问题挺典型的，我之前也踩过。QLoRA微调后权重分布变了，再用gptq量化精度损失会放大，vLLM里LoRA动态合并确实会拖速度。可以试试把LoRA权重合并进基座后重新量化导出，或者直接用AWQ替代gptq，对微调后权重更友好些。另外max_model_len降到2048先测测，有时候KV cache开销比你想的大。

这个OOM基本是KV cache吃满导致的，4k上下文下Llama 3.1 8B每个并发大概要占1G多显存，三个并发叠加权重和激活就顶不住了。你可以试试把vLLM的gpu_memory_utilization压到0.85左右，再手动设max_model_len到4096而不是默认的模型最大长度，这样KV cache的预留空间能省不少。max_num_batched_tokens调小到2048左右会

这种涉及边界条件的逻辑任务，Agent确实容易翻车，ast分析本身不难，难的是它得同时记住递归、跳过__init__、还要输出可读建议，稍微漏一个约束就跑偏。我的经验是别指望一次prompt搞定，先把需求拆成几步让它分步确认，比如先只做扫描、再加过滤、最后拼输出，每一步都跑一遍测试再往下走。另外可以让它先写几个边界用例当“验收标准”，它自己对着用例改比对着文字描述改靠谱多了。至于流程图，我觉得用处

7B微调开compile基本就是给自己找罪受，dynamic shape那块坑太多，我后来直接关了。

512切块对问答来说偏大了吧，试试256加BM25混合检索，bge配稀疏向量效果会好很多。

7B模型单卡40G微调确实挺极限的，但BS=1还OOM有点不对劲。你dataloader里padding是不是没做动态长度？如果每个样本都pad到max_len，那显存占用直接起飞。另外fp16 loss震荡试试bf16，A100原生支持，稳定性好很多。还有optimizer别用AdamW全量，换8-bit或者Adafactor能省不少。

70B的权重光FP16就140G了，8张3090理论够但KV cache和激活值一占就紧张，vLLM默认gpu_memory_utilization是0.9，你调成0.85试试能留点余量。tp=8确实通信开销大，3090又没NVLink，走PCIe交换慢得一批，不如tp=4配pp=2，跨节点通信少一半。真要省显存还是上AWQ或者GPTQ int4，70B量化后大概40G左右，4张卡跑tp=4就很舒

512字符固定切确实太粗暴了，碰到小标题和列表基本必碎。我之前也遇到过类似情况，后来改成按标题层级+语义段落切，召回明显好转。你的case感觉更像是分块把“违约金计算方式”这个完整语义单元切散了，embedding再好也救不回来。建议先别急着换模型，拿几个bad case手动重切一下，对比召回效果，能快速定位是切分还是模型的问题。

50条测试集确实太少了，20个类摊下来每类才两三条，改一版prompt这边涨那边跌大概率就是采样噪声，不是真实信号。建议至少把测试集扩到每类20条以上，哪怕用GPT-4o帮你从历史工单里批量标注再人工抽检，也比现在这样盲调强。prompt版本管理我用过最土但最有效的办法就是丢进git，每个prompt一个文件加版本号，commit message写清楚这次改了什么、动了哪些类别，回滚的时候特别省事

我们去年也是类似场景，几十万中文文档，最后选了Milvus。部署确实要花点功夫，但用docker compose其实还好，主要是etcd和minio这些依赖得理清楚。中文混合检索我们是在应用层做的，向量召回后再用BM25补关键词，效果比纯向量稳不少。Weaviate的混合检索内置得更好，但中文分词这块确实得自己折腾，如果团队人手紧张可以再权衡下。

几百条数据3个epoch太少了，模型基本没学到东西，先把数据量堆到几千条再说吧。

学习率2e-4对LoRA来说有点高了，降到1e-4或5e-5试试，乱码八成是训飞了。

状态共享这块可以看看Redis做Agent间缓存，显存问题八成是模型实例没隔离干净。

MCP管的是上下文状态，DDP管的是梯度同步，这俩其实不在一个层面上，冲突感更多是设计上没拆干净。你推理阶段维护的client上下文如果参与了反向传播，那确实会被DDP的allreduce搅进去，建议把在线学习那块单独拎出来做异步更新。我之前试过用参数服务器思路绕开DDP，推理走本地上下文，梯度攒一批再异步推，效果还行但一致性得自己兜。好奇你是在线学习真实场景还是实验性质？

500的固定切分对这种混合文档确实容易把步骤切断，我之前也踩过这坑。你可以试试RecursiveCharacterTextSplitter按标题层级递归切，再对超长段落做二次语义切分，bge-large-zh配这个组合效果会好不少。另外rerank真的建议加上，bge-reranker或cohere都行，top-k召回里噪声太多，直接喂LLM不胡编才怪。还有个细节是PDF解析出来的换行和页眉页脚要

我最近也在折腾这个，试下来最管用的还是加一层cross-encoder重排，比如bge-reranker或者cohere的rerank，先把top_k拉到20再压到3，效果比单纯调k稳多了。chunk这块也别切太碎，带点重叠和上下文标题，不然后面重排也救不回来。MMR确实不太稳，它偏多样性，跟你要的“只留最相关”其实有点冲突。