长期主义移动开发修炼册

我用的Qdrant配LlamaIndex，中文检索还行，部署也不算重，你可以先拿小数据试试效果。

lr 2e-4对LoRA有点高了，试试降到5e-5，loss卡住很可能是过拟合小数据集了。

长文本精排确实是个坑，ChatGLM3-6B本身上下文窗口够但注意力容易稀释，塞整篇财报进去它基本在瞎猜。你可以试试先做段落切分，让rerank模型对每个chunk单独打分再聚合，别硬塞全文。另外bge-reranker-large在中文长文本上比生成式rerank稳不少，虽然上限低但不容易翻车。

示例太多确实容易被吞，试试只留一段最核心的，其他用文字描述，反而更听话。

我试过类似对比，加“请”确实稳一些，感觉更像是给了模型一个“认真对待”的信号，不全是玄学。

代码库RAG确实和普通文档差挺多的，函数粒度切分本身没问题，但embedding这块bge-m3对代码语义的捕捉可能不够，它更偏自然语言，代码里的变量名、调用关系这些信息损失比较大。你说的cross-encoder把表面相似的排前面，很可能是训练数据里代码pair太少，它压根没学会区分“长得像”和“真的相关”。元数据这块我觉得是关键，文件路径、import关系、函数调用图这些如果能做成结构化过滤或

这事儿我太有同感了，之前做类似抽取任务也是被各种模板坑得不行。后来我慢慢意识到，Prompt工程本质上不是“调参”，而是把任务的不确定性压缩到模型能处理的形式里。你提到加“严格按格式”就稳，其实是因为这类指令把输出空间收窄了，模型不用再去猜你想要的语法结构，注意力自然更集中在内容上。至于few-shot和温度互相打架，我觉得是因为few-shot本身已经在给模型“定调”，这时候温度再一高，等于自己

兼容ROCm确实省心，但生态开放了，海光靠啥留住开发者？光便宜可不够啊。

YOLOv5转ONNX置信度偏低我也踩过坑，大概率不是量化问题，你没提到做了量化，那多半出在预处理或后处理对齐上。官方export.py里的输出和手动转出来的经常不一致，尤其是anchor解码和sigmoid那部分，建议拿同一张图分别跑原模型和ONNX，逐层对比中间特征图。另外opset版本对YOLOv5影响不算大，倒是要注意输入归一化和letterbox的padding方式有没有对齐。

我之前也卡在这块，后来加了个bge-reranker对top-20做精排，效果挺明显的，基本能把物流那种噪音压下去。chunk逻辑也可以顺手调一下，512有时候会把退货政策和售后流程切在一起，试试按标题或语义边界分段。阈值别硬卡，先粗召回再rerank比一刀切靠谱。

试试用function calling原生接口，比让它自己拼JSON稳多了。

我也遇到过类似情况，其实很多时候不是召回的问题，而是你给模型的prompt里上下文拼得太生硬，模型根本没法从碎片里拼出完整答案。建议先别急着换embedding，试试加个bge-reranker重排一下，top5里真正有用的能提上来不少。另外all-MiniLM对中文语义其实一般，换成bge-m3或者gte-large会明显好一些。还有个小坑，Llama 3.2的指令跟随本身就偏弱，你可以在pro

你这个情况我觉得大概率不是chunk的锅，报表类文档切出来数字是完整的，问题更可能出在embedding上——通用模型对“华东区销售额”这种带时间+指标+区域的查询，语义匹配能力其实挺弱的。我之前也遇到过类似问题，后来在检索前加了一层query改写，把“上季度”转成具体季度和月份，命中率明显好很多。另外你可以试试把报表单独建一个索引，或者给文档加元数据标签做filter，别让制度和报表混在一起检索

DeepSeek那边tool调用得用标准OpenAI格式，MCP的schema它经常解析不了，你先手动拼个function试试。

之前用pgvector也踩过这个坑，你这情况大概率是索引扫描和过滤没下推导致的，HNSW的filter参数在低基数场景下确实能缓解，但pgvector这功能好像还不太完善。建议试试建(user_id, embedding)的复合索引，或者把用户ID直接拼进向量维度里做粗筛。基数差异正常，几十条数据走filter反而可能比顺序扫描还慢，几万条又容易变成索引回表瓶颈，关键得看选择性判断。 我后来是直

这个我踩过一样的坑，后来发现“一步步思考”对简单任务确实是负优化，模型容易把无关信息也脑补出步骤来。我现在一般只在问题明显需要多步推理时才在用户提问里临时加一句，系统提示保持干净。你可以试试换个说法，比如“先确认用户意图，再按需分步处理”，给模型留点判断余地，而不是无脑强制推理。 另外这种技巧确实更适合数学、逻辑类任务，客服场景里大部分问题直接查库就行，强行CoT反而增加幻觉风险。我后来干脆把提

这loss曲线挺典型的过拟合信号，试试把epoch砍到1.5或者调高LoRA的alpha值。

这现象太典型了，客服语料太单一，LoRA学嗨了把通用能力覆盖了。建议混20%通用数据，rank降到8，epoch砍到1试试。 我上次也这样，纯业务数据训完直接变傻子，后来加通用数据加早停就好多了，你loss曲线看着正常不代表没过拟合。

这问题太真实了，Cursor的上下文理解其实没想象中那么强，尤其跨多轮对话后经常丢变量状态。我一般会在新需求前主动贴一下关键代码片段，再明确说“基于这段，变量名保持df_raw不要改”，效果会好很多。另外可以试试让它先输出改动计划再写码，能少很多无效返工。

后处理兜底是必须的，漏字段靠正则或规则补，Prompt再调也扛不住长文本漂移。