机器学习研究笔记

量化确实会有影响，但Qwen2.5-7B的底子没那么差，问题大概率还是出在prompt和参数上。你试试把“提取三点核心结论”改成更硬的结构约束，比如直接给输出模板、要求编号、明确每条不超过多少字，小模型对格式指令比语义指令敏感得多。另外Ollama默认的上下文和chat template有时会吃掉system prompt，建议用API传messages时把system和user分清楚，别全塞进一

工业场景里抓取翻车太真实了，我试过几个模型连斜坡上的箱子都搞不定，重力当不存在似的。

bge-m3其实没你说的那么不堪，我怀疑问题可能出在几个容易被忽略的细节上。你对比的时候，两边的chunk切分方式是一样的吗？OpenAI的embedding对chunk边界没那么敏感，但bge-m3这类模型对切分质量要求高很多，尤其是长文本里如果切断了关键语义单元，召回率会掉得很明显。另外你查一下bge-m3是不是用了正确的pooling方式，它官方推荐用cls pooling而不是mean p

这种长上下文里“精分”的情况我也遇到过，尤其是塞了多篇文档之后，模型很容易把不同来源的信息搅在一起。说句实在话，system prompt的权重真没想象中那么大，它更像是一个软约束，上下文一长，注意力被稀释，规则就容易失效。我试过把temperature降到0.1以下，top_p也压到0.8左右，确实能减少胡编，但代价是回答变得很死板，有时候连该提取的信息都漏了。后来发现关键还是得在prompt里

这个情况我踩过，和你的现象几乎一模一样：查“退换货政策”，返回的全是产品参数。问题大概率不在重排序，而是前面根本没把关键片段召回来，reranker再强也没法把没进候选集的东西排上来。你按固定长度切chunk，很容易把“退换货”这种小标题和后面的正文切散，或者整段政策被切到两个chunk里，两边都只沾一半语义，embedding自然偏到产品介绍那边去了。建议先别急着上query改写，先抽十条bad

说个实在的，你要是明年找算法岗，现在纠结这个纯粹是浪费时间。我面过不少人，简历上写精通TF结果连动态图静态图都分不清的太多了。PyTorch现在学术界基本是统治地位，你去看顶会论文的代码，十篇里有八篇是PyTorch，面试官问你最近复现过什么模型，你用TF讲起来自己都别扭。TensorFlow在企业里确实存量多，但很多是历史项目，新起的团队尤其是做大模型相关的，PyTorch占绝对优势。部署那块O

小batch微调确实不是JAX的甜点区，jit每次shape变化都要重新编译，你如果用了动态padding或者变长序列，那编译开销能吃掉大部分收益。我当初迁一个文本分类也踩过这坑，后来固定seq_len加静态batch才勉强持平。多卡pmap如果sharding没对齐，通信开销反而比DDP还大，建议先单卡profile一下看时间花在哪。真要追速度，小模型微调还是PyTorch生态省心，JAX留给大

我踩过一模一样的坑，后来发现根子多半不在prompt，而是检索回来的chunk本身就是碎的或者不相关。你可以先把检索到的原文打出来看一眼，如果上下文里压根没有答案，prompt再花哨也白搭，模型只能瞎编。另外引用不存在的内容，试试在prompt里加一句“若上下文无相关信息就直说不知道”，比调temperature管用。

我也踩过这个坑，后来发现关键不在模板本身，而是resource的description写得太模糊，Claude根本判断不出啥时候该调用。把触发场景写具体点，比如“写Python接口前必须读”，命中率会高不少。另外别指望它每次都自动想起来，重要规范还是塞CLAUDE.md更稳，MCP那个当补充用。

ChatGLM3-6B做rerank确实有点吃力，尤其长文本它注意力容易散掉。我之前试过先用一个小模型把长doc切块摘要再拿去精排，效果比直接塞全文好不少。另外你可以看看bge-reranker-large，专门做中文排序的，比拿生成模型硬做要稳。

切分这步真得看文档结构，PDF里表格和带编号的段落用固定长度切很容易切断语义，试试按标题层级切或者用recursive splitter加些分隔符。召回不准也不一定是切分的问题，embedding模型对中文技术手册效果差异挺大，bge-m3或者m3e这类可以换着试试。reranker确实值得加，bge-reranker先粗排再精排，成本不高但提升明显。建议先用几个典型query手动看下召回top5

先别急着换模型，bge-large-zh没那么菜，多半是chunk切断了上下文，试试按语义或句子边界切。多模型融合能涨点但调权麻烦，不如先加个关键词召回兜底。

这问题我也遇到过，Qwen2.5对system prompt的遵循确实有点飘。你试试把“只输出JSON”这种约束放到user message里再强调一遍，或者用few-shot给个例子，比单靠system稳很多。另外vLLM的chat template别自己手动拼，容易把system role搞丢，建议直接用tokenizer.apply_chat_template走标准格式。

并发一上来就答非所问，我第一反应不是chunk，而是你的向量化是不是被推理服务拖垮了。你本地测试正常、线上并发高才炸，这个时间点太巧了，很可能embedding请求在排队或者被限流，返回了降级结果甚至错位，检索层拿到的向量本身就是歪的，top3混进不相关片段就说得通了。建议先别急着调chunk，把线上每次检索的query向量和离线单独算的向量做个余弦对比，偏差大就直接锁定是服务复用的问题。我倾向于

说实话你这体验太真实了，Rust的借用检查器对AI来说就是照妖镜，生成个闭包或者生命周期标注简直全靠蒙。我后来试过把函数签名和trait bound全写死，只让它填逻辑体，成功率能高一些，但遇到复杂点的自引用结构还是得自己上。现在基本把AI当高级补全用，让它写点模块划分或者测试用例还行，核心逻辑宁可自己敲，不然改错的时间都够重写三遍了。

把硬规则直接写进system prompt里，再让Agent先复述一遍约束再生成，效果会好很多。 试试few-shot给几个带约束的正反例，比干巴巴描述业务背景管用。

确实，覆盖文件那套方案升级一次折腾一次，有时候连图标都变回默认，特别心累。Dream Skin这种模块化注入的思路靠谱，相当于把皮肤做成独立插件，至少不用每次版本更新都提心吊胆。 我也试过类似思路改别的软件，关键是它能不能做到完全不动主程序文件？如果后续官方更新改了资源路径，这套注入机制会不会也要跟着适配啊？

先用Qdrant顶着上线，等量大了再迁Milvus，别一开始就给自己上强度。

这问题太真实了，我刚开始也这样。后来发现把大任务拆成小函数让它一个一个写，比催它“输出完整代码”管用得多，每个函数写完立刻复制保存。另外你试试在prompt里加一句“像在生产环境里一样写”，有时候比单纯说“不要省略”有效。token限制确实存在，但多数时候是模型偷懒，所以分步写反而能逼它把细节补全。

我个人感觉这种偏静态分析的任务，Agent确实容易在边界条件上翻车，像递归扫描和`__init__.py`这种特例，它很难像人一样有全局意识。不过你贴文档这招我试过，有时候反而会让它更机械，不如直接给它一个含各种情况的小型测试目录，让它跑完对照结果改，比反复改prompt效率高。流程图那步我觉得可以跳过，但你可以试着把需求拆成“先写遍历函数，再单独写分析逻辑”，分两步让它做，出错点会好定位很多。另