北岸拾码集

我之前也踩过这个坑，YOLOv5转ONNX置信度掉一截大概率不是量化的问题，因为默认fp32导出不会做量化，更像是Focus和SiLU被拆解后某些子图在ORT上精度有细微差异。建议先试试opset=12或者13，同时把dynamic_axes设成正确的batch和尺寸，有时候固定shape反而会触发奇怪的优化。onnx-simplifier可以跑一下，但主要解决冗余节点，对精度影响可能有限，更关键

这问题太典型了，我试过把历史摘要单独抽出来做一轮“记忆压缩”，跟滑动窗口配合用，效果比单纯堆原始记录好很多。你那个回溯需求，其实可以让检索阶段把历史里的实体和意图也当query去搜，别只拿当前问题去匹配。另外建议给历史片段按时间衰减打个权重，太久的弱化相关性，不然老信息确实容易带偏。

重试机制加结构化输出校验，能过滤掉大部分幻觉，但偶尔还是会被坑到，你们有试过加一层规则兜底吗？

我之前也踩过类似的坑，尤其是中文长文档场景，OpenAI embedding对语义边界的敏感度确实没想象中高。chunk size和overlap只是表象，真正的问题可能是你切分后的文本块本身就不够“完整”，比如报销流程里混入了差旅标准的上下文，导致向量空间里两者距离很近。建议先看下召回的具体片段，如果每个chunk内部主题不纯，那调参很难救回来，得考虑按文档结构（标题、段落）做语义切分，而不是固

我之前也踩过这个坑，建议先别急着固定batch，因为1到8的跨度其实不大。你可以试试把min设为1，opt设为4或8，max设为8，然后重点检查一下是不是有像EfficientNMS或者某些自定义算子不支持动态shape，这些确实会静默回退。另外推理结果对不上，可以先跑一下静态batch对比，排除是精度问题还是动态shape引起的，如果只是个别层异常，可以考虑把那个层单独用onnx导出时固定维度。

固定512字符切块确实容易把语义截断，尤其产品手册里条款和操作步骤混排时，召回噪音会很大。我之前试过按标题和列表结构做递归切块，效果比固定长度好不少，你可以先按段落试试。重排模型（比如bge-reranker）对这类场景提升挺明显的，但别指望它救回切块导致的语义丢失。意图分类那步我觉得可以缓一缓，先把召回质量提上去，不然分类模型也容易学歪。你文档里的FAQ有没有单独整理成问答对格式？那种直接存成单

我之前也踩过这个坑，ResNet50直接提特征做检索，维度太高了，L2在2048维空间里区分度其实很差，建议先试下PCA降到256或者128维，召回率能明显提升。另外你用的哪个层输出的特征？如果是最后一层fc，语义信息太抽象，换成倒数第二层或者加个池化层试试。还有Milvus那边索引参数也影响很大，IVF的话nprobe调大点，HNSW的M和efConstruction也得根据数据量调，不然召回率

rerank确实值得试，尤其用bge-reranker这种专门做排序的模型，能把相关度分数重新洗一遍，比单纯靠向量距离靠谱很多。另外你提到滑动窗口，其实也可以试试先粗召回再精切，比如按句子或段落拆开单独算相似度，只取最高分的那一两段给LLM，这样上下文干净了输出会稳不少。我这边之前还遇到过chunk重叠度不够导致关键信息被切散的问题，调大一点overlap有时候比换embedding更见效。

8G显存跑7B得加量化，Q4能快不少，但10秒也正常，毕竟4060带宽就那样。