持续研究产品研究簿

维度不是越高越好，关键看模型和场景，混用不同维度得各自建索引再融合，别硬拼。

微调能治标但数据得下功夫，工具定义混着正反例一起喂，不然换个问法照样翻车。

我一般会在项目根目录放一个.cursorrules文件，把关键依赖的版本和用法示例写进去，比在prompt里临时说管用多了。Pydantic v2和v1的差异确实坑，我直接贴一段v2的model_config示例给它看，后面基本就不乱写了。不过说实话，依赖这块我还是会自己过一遍，AI当草稿用就行，别全信。

编号和分隔符真的有用，我习惯给每个chunk标上[1][2]，然后要求模型引用时带上角标，缝合情况少了很多。另外“原文没有就直说不知道”这句最好写成硬性规则放开头，别放在末尾，模型对前置指令更敏感。开源模型确实得更直白，像Qwen得反复强调“只能依据上文”，GPT-4相对省心但也别指望它百分百老实。

我之前也踩过这个坑，7B量化在CPU上跑并发基本没救，延迟比云端还离谱。后来换成vLLM加GPU，单路快很多，但MCP场景请求零散，资源利用率又上不去。传输这块HTTP轮询确实拖后腿，可以看看MCP的SSE或者streamable HTTP，首token能快不少。云端API胜在省心，就是波动真看运气，敏感场景建议做超时和降级兜底。

这个坑我踩过，而且踩得挺深。你遇到的问题其实挺典型的，CoT对任务类型很挑，不是万能药。像客服问答这种场景，很多问题本来就是查表或者匹配意图就能搞定的，你让它一步步推理，等于逼着模型去“编”一个不存在的思考链条，反而把简单问题复杂化了。我之前也试过在系统提示里加类似的话，结果模型连“今天天气怎么样”都要给我分析三步骤，纯粹是浪费token。后来我的做法是分场景处理，简单意图识别类的请求干脆不加任何

loss卡在1.8还带震荡，加上验证集开始复读标点和指令，这个信号挺明确的，八成不是学习率的问题。LoRA本身可训练参数少，1e-4到3e-5这个区间已经算比较宽了，真要调不出花来，问题多半在数据那侧。你只做了去重和粗切分，没做指令格式化，爬来的论坛帖子本身就带着大量口语、引用、断句甚至乱码，模型很容易把这些当成模式学进去。复读标点其实就是它在模仿脏数据里的结构，而不是在学任务。至于加大数据量，如

召回准不代表生成就稳，问题往往出在context拼接上。你把5个片段直接塞进去，模型很容易跨文档“串台”，尤其是数字和结论这种强模式化的内容。可以试试在每个chunk前面加来源标识，prompt里明确要求“每个结论必须标注来自哪份文档”，逼它做引用对齐。换7B模型不一定更好，小模型反而更容易补全没见过的信息。另外生成后再加一层校验，拿输出里的关键数字回召回片段里做字符串匹配，对不上的直接打回重生成

我之前也踩过这个坑，loss降得好看不代表检索就变好，因为对比学习的目标跟检索评估之间其实有个gap。你用的正负样本对如果构造得太随意，比如负样本是随机采的，模型很容易学到一些表面特征，反而把原本通用模型学到的语义空间给带偏了。特别是bge-small这种参数量本来就小的模型，微调几轮之后很容易过拟合到你的训练分布上，泛化能力掉得厉害。建议你先别急着怀疑学习率，拿MTEB或者自己标注的测试集跑一下

我们之前也踩过这个坑，后来改成每次检索前先用当前问题加最近一两轮对话让模型重写一版query，再去向量库搜，效果比直接拿原始问题搜好很多。历史记录不用全塞，做个滚动摘要就行，把之前的关键信息压缩成几行，比滑动窗口灵活。另外可以给历史加个时间衰减权重，越早的对话对当前检索影响越小。你们知识库文档粒度怎么样？如果切得太碎也容易让检索被无关历史带跑。

AWQ 4bit还OOM有点怪，先试试把gpu_memory_utilization降到0.85，再把max_model_len砍到4096，KV cache能省一大截。

我之前也遇到过一模一样的情况，loss降了但生成彻底崩掉。后来发现是数据里夹杂了太多英文标点和特殊符号，清洗干净后立马正常了，你可以先检查下这个。另外5e-4的学习率对LoRA来说确实偏高，尤其rank才8，试试降到1e-4或者2e-4，epoch减到1-2个看看。还有个小坑，中文alpaca格式里有些模板带了英文指令前缀，模型可能学到那种混杂模式，最好统一成纯中文prompt再试。

之前我也卡在这过，后来发现是SDK版本和Claude Desktop的传输协议对不上，0.6.0默认走的是新版握手，但桌面端还在用老格式。你试试把SDK降到0.5.x，或者直接在初始化时强制指定legacy协议，我这么改完stdio立马就通了。另外SSE那边注意URL别带尾斜杠，有时候服务端会重定向导致握手失败，这坑挺隐蔽的。

这问题我太熟了，之前搞法律文书问答也栽在术语混淆上。个人建议先别碰Embedding微调，bge对领域词本来就弱，你花大代价调完可能只是过拟合那一小撮词。性价比最高的是微调Reranker，用你标注的那几十对正负样本就能见效，直接治“量子退火”和“退火工艺”这种硬伤。LLM微调放最后，因为生成端对术语的理解更多靠prompt里塞few-shot示例就能缓解，成本完全不是一个量级。

这问题太真实了，GPT写脚本就像挤牙膏，你催一下它动一下。我试过把需求拆成函数级别让GPT逐个生成，再手动拼起来，比一次性要完整代码靠谱得多。另外你试试在Prompt里加一句“不要省略任何import和错误处理”，有时候它默认你懂就偷懒了。最后实在不行就让它报错，把报错信息丢回去让它自己修，来回两三次基本能跑通。

之前调RAG也踩过这坑，500的chunk对技术文档来说确实容易语义断层，尤其PDF里表格和代码块混在一起的时候。可以把chunk_size提到800到1000，overlap加到150试试，另外试试按标题或段落结构切分，比纯字符切靠谱很多。Embedding的话换bge或者e5系列通常比默认的text-embedding-ada-002更稳，如果文档偏内部术语，有条件微调一下效果提升会很明显。r

实际项目里embedding模型定死就行，换来换去坑的是自己。1536维直接跑，召回率不行先查chunk切分和检索方式。

few-shot基本是刚需，单靠一句话触发不了稳定推理，尤其简单任务模型真会偷懒。

说实话你这情况我太熟了，chunk size固定500对PDF这种格式来说挺吃亏的，尤其表格和代码块会被切得稀碎。我建议先试试按文档结构（标题、段落）做自适应切分，再给每个chunk打上文档名、章节路径这些元数据，检索时按企业部门或文档类型过滤一下，涨点比换模型快。parent-child结构也值得试，用大块做召回、小块喂给LLM，我这边top5能提七八个点。微调embedding先别碰，你这数据

500条确实少了，LoRA在这种风格迁移任务上容易过拟合，试试加到2000条以上或者调低学习率。