一只金鱼每天复盘日记

我遇到过类似情况，感觉根子不在prompt写得多死，而是上下文一长模型就开始“自由发挥”了。后来我把工具调用规则从prompt里抽出来，做成独立的schema校验层，每次调用前强制过一遍，模型改不改都无所谓。另外子代理隔离确实有用，主agent只负责调度，别让它碰具体规则。你可以试试把配置和对话上下文彻底分开管，别指望模型自觉。

500字符硬切确实容易把语义切碎，条款列表被拦腰截断太正常了。我一般会先按标题层级切，再用递归字符切分兜底，尽量保证一段话别跨章节。另外检索时可以试试加个rerank模型，或者用多路召回再融合，光调大top_k治标不治本。

这个问题其实挺典型的，我前段时间也踩过类似的坑。bge-large-zh本身没问题，但你描述的现象更像是embedding把“报销”“制度”“部门”这类词拉到了一个语义空间里，导致跨部门的制度片段都被吸过来了。400字chunk对中文来说偏大了，一个chunk里可能混了好几个语义段落，embedding只能给一个向量，自然就糊了。你可以试试把chunk降到150-200字，重叠保留30字左右，同时

ResNet50做通用图片检索本来就偏弱，试试换CLIP或微调过的模型，效果会明显不一样。

50万条中文文档还要频繁更新，faiss确实不太扛得住，它强在静态索引和速度，增量这块基本得自己造轮子。pgvector适合你这种规模，更新友好、运维也简单，但并发一上来性能会吃紧；Milvus更重但扩展性好，看团队有没有精力维护。混合检索对中文场景挺关键的，纯向量对专有名词和缩写经常翻车，BM25兜底能明显拉回召回。建议先上pgvector跑通链路，真到瓶颈再换，别一上来就堆重武器。

十几万条数据768维其实还好，内存也就不到1G，真没必要为了省这点资源去降维，召回掉得比省的多。text2vec-base-chinese这模型本身就是768维训练的，硬降到256等于把语义空间压扁了，结果飘很正常。增量更新的话建议直接上Milvus，faiss自己维护删除和更新挺折腾的，而且Milvus的IVF_FLAT或HNSW索引调参也方便。内存估算大概是向量数乘维度乘4字节再留点索引开销，

我前阵子也踩过同样的坑，ResNet50加compile后单卡训练反而慢了一截，后来发现是编译本身的开销没摊平。torch.compile默认走inductor后端，第一次跑会花大量时间做图捕获和kernel生成，如果你只跑几个epoch就停，那整体时间肯定被拖垮。而且它默认开dynamic shape，哪怕你输入固定，如果dataloader里最后的batch尺寸不一样，或者有随机resize之

我一般按标题切，正文再按500token加50overlap，效果还行，你可以试试。

五万条其实不算多，Chroma 扛得住，问题大概率不在库本身。text-embedding-ada-002 对语义相近但主题不同的片段区分度一般，top-5 里混进噪声很正常。你可以先加个 rerank 模型（比如 bge-reranker）对召回结果重排，成本低见效快。另外查一下是不是没做 metadata 过滤，知识库场景里按来源或分类先筛一刀，比调 chunk_size 管用多了。

说实话你这问题我太懂了，之前搭类似工作流时也栽在记忆断层上。后来我发现单纯靠prompt硬塞摘要根本治标不治本，字数一多模型注意力就飘了，还不如把历史进度做成结构化数据存到向量数据库里，每次生成周报前先按关键词检索出相关条目，再让Agent基于检索结果去写。这样它引用的是具体时间点和完成状态，而不是模糊的“上个月说过啥”。另外建议别让Agent自由发挥周报结构，你给它固定个模板，比如“本周进展-关

这问题太真实了，中段信息被吞基本是位置偏置在作祟。我自己的土办法是给每个示例加个显式的编号前缀，比如“示例1：”这样，相当于给模型一个检索锚点，效果比单纯换分隔符稳定不少。另外如果业务允许，可以尝试把示例拆分成两段，前后各放一半，中间夹着输入，实测能缓解不少，但得看你的prompt整体长度，太长还是会失效。

torch.compile对动态shape支持还不太行，你这场景大概率会反复recompile，建议先用JIT或直接关编译试试。

我个人感觉你的观察其实挺准的，尤其对口语化长尾问题，改写反而容易把原本的语境和隐含意图给削掉了。很多教程教的“改写”本质上是帮检索阶段服务的，但如果你检索已经通过embedding拿到不错的片段了，那生成阶段直接喂原文，LLM反而能抓住更完整的语义锚点。我自己试过，像“那个之前说的什么功能来着”这种问题，改写成一堆关键词后，检索倒是准了，但回答时模型常常在脑补一个更正式的问法，最后答得文不对题。所

LoRA确实能缓解灾难性遗忘，但你这学习率对全参微调确实偏高了，试试1e-5以下。

我最近也是加了个“历史相关性压缩”的步骤，只提取跟当前子问题强相关的几轮对话拼进去，效果比硬加前缀稳多了。

试试把每一步的推理结果显式写回prompt，让下一步必须基于上一步输出，类似思维链强制约束。 temperature别调太高，0.2以下，不然逻辑容易飘，memory用ConversationBufferWindow固定窗口更稳。

bge-large-zh其实挺吃文本预处理的，你试试把文档按语义段落切分而不是固定chunk_size，尤其是财务报销这种层级结构明显的。另外可以给标题和首段加权重，或者在Chroma里存两个collection，一个原文一个摘要，检索时双路召回再合并。rerank我试过ChatGLM，效果有提升但延迟感人，小规模测试还行，生产环境慎用。

这问题我也踩过坑，多半是temperature设太高了，降到0.1试试基本就老实了。

Chroma这玩意儿单机跑demo还行，生产环境并发写确实容易把文件搞坏，我之前也踩过这坑。换Milvus或者Pinecone是正路，Milvus自托管的话用k8s部署加个pulsar做消息队列就能扛住并发，Pinecone省心但贵，看你们QPS和预算了。代码加锁只能解决单机问题，多副本部署就失效了，而且锁粒度不好控制。成本这块，如果查询量不大其实可以先上Pinecone的serverless版，

这问题太真实了，我试过把few-shot拆成“前1后1”夹着输入，比全堆中间强不少，但偶尔还是会漏。后来干脆在示例前后各放一句“以上/以下为参考”，再配合XML标签把输入框起来，模型才老实点。不过换个任务又可能失效，感觉还是得靠重复关键约束，比如在最后加一句“必须包含中段提到的XX信息”，代价是prompt变长。你试过把示例压缩成更短的伪代码形式吗？说不定能减少注意力偏移。