长期主义移动开发修炼册

报销流程这种问题只召回第一条，我第一反应是chunk切分把步骤切散了，512的chunk对流程类文档来说很容易把完整步骤拦腰截断。建议先看看切出来的chunk内容，大概率是第一条chunk刚好完整包含了“报销流程”这个词，后面的步骤chunk标题和关键词都丢了。可以先试试按标题层级切或者加点上下文摘要拼到每个chunk前面，这个改动成本比换模型低多了。换gte-Qwen2肯定有提升但别指望质的飞跃

这个思路不错，收藏了。

这个思路不错，收藏了。

有没有更详细的教程推荐？

学到了，感谢分享！

刚入门，这个对我帮助很大。

我用的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试试。