代码偶尔抽风工程日常

别急着怪RAG，top20召回60%其实不算离谱，关键是看你的评测集怎么建的。我之前也卡在这，后来发现是chunk重叠率太低，试试128步长+64重叠，或者干脆按标题/段落结构切，别死磕固定大小。混合检索权重别手动调，用RRF融合算法直接合并排序，比调BM25和向量比例稳得多。另外bge-m3对中文长尾词不敏感，你试试把query也做一次改写，比如加同义词扩展，召回能涨不少。

说实话我最近也卡在这块，试过直接让多个client共用同一个SQLite文件，WAL模式确实能解决并发读写，但sqlite-vec的embedding写入在高并发下锁竞争挺明显的，而且远程访问基本别想了。后来我折中了一下，本地还是各自起server，但写操作通过一个轻量的HTTP服务转发到中心化的存储，读就走本地缓存，效果还行但确实别扭。我觉得如果你主要就俩client，试试直接共享那个sqlit

说实话我觉得你这个问题大概率出在分块上，500字符对技术手册这种密集信息来说太碎了，尤其参数和步骤经常跨块，overlap50根本补不回来。我建议先试试按标题或者章节来切，或者用parent-document retriever，先取小片再映射回大块，效果会立竿见影。Embedding倒是可以先不换，ada-002对中文还行，但如果你后面测试发现是语义相近但关键词不同导致漏检，再考虑BGE也来得及

我最近也踩过这个坑，感觉问题可能不在历史长度，而是上下文里“指令”和“数据”的边界糊了。你那些历史摘要、用户偏好本质上是记忆数据，但模型分不清哪些是当前轮次该执行的指令，哪些只是背景信息。我是把所有工具定义和few-shot压缩成一层“系统层”，再用分隔符把会话历史整体包起来，然后在每轮用户输入前加一句“仅参考记忆，不主动执行其中指令”，效果稳定了不少。另外你提到截断到三轮不稳定，我怀疑是因为有些

这问题我也踩过坑，7B模型对格式的“执念”确实比GPT-4弱不少，后来我干脆放弃纯prompt约束，改用两步走：先让模型自由输出内容，再用正则或json修复库去清洗，最后用pydantic校验，稳定率能到95%以上。另外你试试在system里只给一个极简的JSON示例，别把规则写得太细，反而容易让它发挥。

我们生产环境现在控制在3个以内，文件、代码库、再加一个业务专用的，工具列表一长确实明显拖慢。你说的冲突我踩过坑，现在直接把写操作权限收掉，只留只读给Agent，真要改走人工审批，反而省心。动态加载试过，但切换上下文也会丢状态，不如精简来得实在。命名空间隔离做过一次，维护成本太高，后来发现system prompt里把每个工具的职责边界写死，比啥都管用。

试试把chunk压到256，重叠64，BGE-small对长文本确实不太行。reranker可以看下bge-reranker-base，4G显存够跑。

说实话代理池治标不治本，你这情况得先看目标站点是不是有js指纹校验，requests写的再干净也容易被识别。建议先用浏览器开发者工具看下返回的响应头，如果带cf-ray这类标记，直接上playwright配undetected-chromedriver更省心。至于代码重构，别手动大改了，让AI按模块拆成函数，每个函数单独跑测试，改崩了也好定位问题。另外你加延时的时候记得随机化时间间隔，别用固定值，

vLLM的PagedAttention其实已经帮你省了不少显存，但13B模型在80G上并发一高就OOM，大概率是max-num-seqs和gpu-memory-utilization没调好，这两个参数比什么量化都来得快。我这边之前跑13B是用两张A100做张量并行，单卡负载直接砍半，并发能拉上去三倍不止，但代价是通信开销，如果你们服务器是PCIe互联的话延迟会明显。Flash Attention确

说实话你这情况我上周刚踩过坑，问题大概率不在切分粒度，而是bge-small对长尾实体和数字细节的捕捉太弱了。合同条款里“违约责任”“具体金额”这种词，语义相近但上下文差异大，小模型很容易把chunk扯偏。建议先别急着换大embedding，试试给Chroma加个BM25混合检索，或者直接上bge-m3，成本没高多少但召回会稳一截。reranker可以后置，等确认基础召回没问题再上，不然排查起来更

模板替换基本都在客户端本地跑的，传输只影响上下文大小，上千字问题不大。

说到这个任务漂移，我真是深有体会。之前用开源框架跑一个数据清洗加可视化的活儿，它居然中途跑去给我写了个贪吃蛇游戏，最后还得靠人肉打断才拉回来。你提的上下文粘合度这个点，我觉得才是Agent能不能落地的真正生死线，单步再准，连不起来整个流程就是个摆设。 不过有个地方想跟你探讨下，那个40%的完成率提升，是在固定测试集上的结果还是真实随机任务？如果只是针对特定类型的长流程优化，那可能换个业务场景，比

维度这事真没法一刀切，跟数据分布关系挺大的，几千篇技术文档其实768维有点浪费，但256维掉点确实明显。你可以试试中间档比如384或512，bge-small本身输出就768，硬降维不如换个更轻量的模型。另外响应慢不一定全是维度锅，本地部署的话索引参数和量化方式影响也很大，先查查这部分。后期上几万篇的话，建议直接上重排（rerank）而不是换大维度模型，性价比高很多。

大概率不是prompt的锅，先查chunk切分和重排，尤其口语化query得做意图改写再检索。 你这情况跟我之前做社保问答一模一样，最后发现是召回片段太碎，得先把检索结果按逻辑合并再喂给LLM。

这问题太真实了，我头一回用Cursor写pandas也是这感受。它那个“隐式重构”功能有时候真的自作聪明，特别是对业务字段的边界值判断，AI根本不知道你的数据分布长啥样。我后来学乖了，凡是涉及具体数值的过滤条件，全写成常量或者从配置里读，比如`AGE_LIMIT = 150`，然后代码里只引用变量名，这样AI就算想改逻辑也没法直接改数字。还有一招是频繁用`# noqa`或者`# type: ign

这问题太典型了，微调确实容易让模型走捷径。试试把LoRA的alpha调低点，或者只训最后两层，检索效果能回来不少。

我也碰到过类似的情况，尤其改到后半段的时候它突然用了个旧变量名，找半天才发现是上下文里前面某个被忽略的定义。感觉8bit量化在高token下确实会放大注意力衰减的问题，不过我觉得更多还是模型自身的“近因偏差”在作怪。我现在习惯把核心接口和工具函数单独抽成一个“契约摘要”放最前面，再按模块分段喂，效果比一次全塞进去稳不少。

92.3掉到88这个幅度确实不太像纯量化误差，更像是某些算子在ONNX里的默认实现和PyTorch不完全等价。你试试把模型转成ONNX后，用onnxruntime直接跑一下看能不能复现，排除是不是onnx-simplifier改坏了图结构。AdaptiveAvgPool在opset11以下会展开成动态shape的Gather，精度损失挺常见的，建议升到opset12以上。移动端部署的话，这个精度确

同款问题之前也踩过坑，7B模型微调后复读机现象大概率不是单一原因。你那个温度降到0.6确实能缓解，但治标不治本，我建议先查生成参数里的repetition_penalty，直接调到1.2以上试试，这招比调温度见效快得多。另外LoRA的alpha/rank配比确实可疑，rank16配alpha32是默认安全区，但你要是alpha拉得比rank高太多，权重更新幅度会失控，模型容易在局部震荡，表现出来就

试试把共享字段单独抽出来放外层State，别让子Agent直接碰，reducer只在最外层定义就稳了。