企业级自动化开发日志

可以在项目根目录加个.cursorrules文件，写清楚只准用我指定的props，比在prompt里喊管用多了。

Prompt确实有用，但没网上吹得那么神。我自己的经验是，SD出图质量七成看模型和采样器，提示词顶多占三成。你提到的画质词堆叠、负面词这些，在特定模型上有效，换个模型可能就翻车了。想提高效率可以试试用X/Y/Z plot脚本，固定其他变量只调提示词，跑几十组对比就能看出哪些词真的有用。纯靠抽卡不如先摸清自己常用模型的脾气。

我最近也在折腾类似的东西，chunk可以试试按语义切而不是死磕固定长度，政策文件里条款边界挺明显的，按章节或条款切效果会好很多。bge-small确实对长文本吃力，其实换个bge-base或者m3e-base在3090上完全跑得动，不一定非得上large。重排序那套双塔+交叉编码器听着唬人，但你可以先用bge-reranker-base试试，加在检索后面成本不高，召回质量提升挺明显的。

先别急着换模型，合同这种长文档固定512字符很容易把条款切碎，试试按条款标题分块。索引影响不大，bge在这类专有名词上其实还行。

这种小bug确实挺常见的，我倒觉得不全是prompt的问题。模型生成代码时对上下文依赖挺强，你试试把每个脚本拆成更小的函数来问，比如单独让它写“带超时重试的requests下载函数”，比一口气生成整个脚本靠谱多了。另外inplace那块我一般直接写df = df.dropna()这种赋值形式，省得它老搞混。变量名拼错的话，可以在prompt里明确说“用有意义的长变量名，别用缩写”，亲测能少踩不少坑

7B做function calling确实容易翻车，我拿Qwen2.5-7B试过类似的场景，不量化或者用q8效果会好不少，q4的话指令跟随能力掉得挺明显。另外你用的prompt模板很关键，最好直接套官方推荐的tool call格式，别自己随便写，不然模型根本分不清该输出工具调用还是普通回复。温度调到0.1以下试试，采样太随机它就容易跑偏去自由发挥。还有一点，7B本身推理能力有限，复杂点的多轮工具调

top-5全塞进去确实容易翻车，我后来改成按相关性阈值动态截断，最多给3条，效果稳不少。你那个先判断相关性的思路可以简化，别让模型逐条打分，直接让它输出引用编号再生成答案，延迟基本不涨。全量测试崩大概率是模板对边界case太敏感，建议把失败样本按“检索错”和“拼Prompt错”分开归类，别混着调。

随机负样本确实容易翻车，换成难负例试试，法律领域术语太像了。

试试用collate_fn自己拼，别在Dataset里搞，维度对不上多半是没对齐padding。

让AI先写测试再写实现，反着来能逼它把边界想清楚，比事后修bug省心多了。

3060跑8B用q4_K_M就行，十几秒可能是没开GPU层数，Ollama拉满试试。

旧项目Copilot基本帮倒忙，我都是关掉补全纯手写，省得跟它较劲。

recall@5六成出头，大概率不是chunk大小的问题，256其实挺标准了。建议先查一下测试集里的query和召回段落是不是真的语义匹配，有时候标注本身就有偏差。我踩过类似的坑，后来发现加BM25混合检索收益最大，尤其是企业文档里专有名词多，纯向量反而吃亏。rerank可以放第二步，但前提是召回池够大，不然也是白搭。

我一般把prompt拆成三块看：任务描述、示例、输出格式，变量分开调就能知道是哪块出问题。分类任务尤其吃标签定义和边界case，例子别瞎加，加错了反而带偏。另外温度那些参数只在输出多样性上有感，分类基本开到0就行。系统学的话可以翻翻OpenAI的prompt engineering guide，再配合langchain那套评估思路，比纯试错靠谱点。

试试把AdamW的eps从默认1e-8调到1e-6，后期NaN经常是它引起的。

召回看着准但生成答非所问，这种情况我踩过好几次，大概率不是单纯rerank的问题。top5里只要有两三条真正相关、剩下的是“看起来相关但没答到点”的噪音，7b模型就很容易被带偏，它不像大模型那样能自己筛掉干扰。你可以先做个诊断：把检索到的片段单独拿出来，人工标注哪些句子真正含答案，再看生成时模型引用了哪些，很多时候问题出在chunk里答案句被无关上下文稀释了。压缩这块我觉得比rerank更值得先做

这个坑我踩过，大概率不是MCP的锅，而是微调时模型压根没见过tool result这种格式。你微调数据里只有系统提示词加对话，但MCP塞回来的是一堆JSON schema和工具返回结果，模型看到这玩意儿直接懵了，注意力全被那些结构化字段带跑偏，自然就“失忆”了。我建议你在微调阶段就把工具调用的完整轨迹混进去，包括tool_calls的请求和tool角色的返回，让模型提前适应这种上下文结构。另外MC

直接写个`.cursorrules`把你平时习惯扔进去，比调教它快多了。

几万篇真不大，纯向量够用，别为融合分数头疼，先跑通再说权限过滤的事。

之前也踩过类似的坑，排查下来多半不是DeepSpeed本身的问题，而是自定义dataset或collator里偷偷把tensor留在了GPU上没释放。试着在trainer里加个显存追踪，每个step打印一下reserved和allocated，能很快定位到是哪一步暴涨。另外你提到demo脚本能跑通，建议直接diff两边data和model的差异，很多时候是padding策略不同导致序列长度远超预期