云端金鱼喜欢开源日记

我之前也踩过这个坑，14B级别模型在长对话里确实容易把系统提示词“忘”在脑后。后来我是把审阅规则拆成几个独立的子任务，每轮只让模型干一件事，比如先只抽争议焦点，下一轮再单独做条款比对，漂移明显少了很多。另外可以试试在每轮用户输入前用固定格式重贴一遍关键约束，但别写太长，三五行就够，比把指令放最后管用。温度调到0.3以下也有帮助，不过根本还是别让单次上下文塞太多任务。

多步任务别硬靠ReAct，试试把流程拆成固定链路或用LangGraph管状态，稳很多。

按行切确实坑，我之前也踩过，函数体被腰斩检索出来根本没法用。后来换成tree-sitter按AST节点切，把函数、类、方法作为最小单元，效果提升挺明显的。Python和Go都有现成的grammar，LangChain里可以自己包一层splitter。另外建议把docstring和函数签名单独存一份做embedding，检索命中率会高不少。

混合检索确实值得试试，纯向量对数字和年份这种细节本来就不敏感，加个BM25把关键词召回一起融合排序，2022和2023这种问题能压下去不少。HNSW的efConstruction影响的是建索引时的图质量，efSearch才是查询时该调的，你可以先把efSearch拉高看看召回有没有变化。query扩展也可以做，但别用LLM瞎扩，容易引入噪声，不如先拿同义词词典或者把问题里的时间、实体抽出来做过滤。

500条确实偏少，loss振荡到2.3更像是过拟合前兆，试试先冻住部分层或者加个早停。

我也遇到过，7B写长函数确实容易断片，换14B后好很多，vLLM采样策略影响不大。

我之前也踩过这坑，后来改用独立state加聚合节点，依赖关系用Send显式触发，稳多了。

角色设定是给生成用的，别混进检索query里，拆开就对了。

我也是FAISS+GPT-4这套，之前踩过一样的坑。建议你加个cross-encoder做rerank，比如bge-reranker，先粗召top-20再用它精排到3-4条，效果比单纯调embedding稳多了。另外你可以在prompt里明确让它只依据给定片段回答，不确定就直说，能压住不少幻觉。

这太正常了，我一开始也踩过一模一样的坑。ChatGLM3的tokenizer和Llama3在padding策略上确实不一样，ChatGLM系列习惯用left padding配合它自己的attention实现，而Llama3那边一般用right padding，直接照搬肯定报错。标签移位那块也是，不同模型对loss计算时shift logits和shift labels的处理顺序有差异，有些教程还会

2.x的loss在LoRA微调里其实挺常见的，尤其你数据量才2万条，模型很难真正学到垂直领域的知识分布。我建议先别盯着loss看，重点看生成质量，车轱辘话往往说明模型没学到有效模式，可能数据里问答对的多样性确实不够。r=8对7B模型偏小，可以试试r=16或32，同时把lora_alpha调大一点，学习率2e-4左右反而可能比3e-5更有效。另外检查下训练时是不是只计算了answer部分的loss，

先别急着调参，把“售后服务流程”这句话单独去FAISS里看top5召回了啥，大概率是embedding没抓住“流程”这种抽象词，换bge试试。

bge-small-zh做中文语义检索确实有点吃力，尤其流程类文本里“离职”和“入职”字面高度重叠，小模型很容易糊在一起。我建议先别急着换接口，可以试试bge-m3，它对中文长文本和多粒度语义的区分明显好一截，而且本地跑成本可控。另外你chunking是不是切得太碎了？流程类文档按标题层级保留上下文，召回质量提升可能比换模型还直接。真要用OpenAI接口，记得先拿几十条badcase对比一下，别盲

几十万条向量真没必要硬上Milvus，FAISS本地跑完全够用，省得折腾那堆配置。我之前做类似规模的项目直接FAISS加一层简单的持久化，效果没差多少。Pinecone免费额度验证原型是够的，但向量一多费用确实肉疼。如果后面要上生产再考虑Milvus也不迟，别一开始就把自己绕进去。

豆瓣这种站其实对请求头挺敏感的，光换UA不够，Referer、Accept-Language这些也得补全，最好直接用session让它自己带cookie。你用AI写的时候可以把“模拟真实浏览器行为”这个需求描述清楚，让它帮你用requests.Session加完整headers，比自己一个个试快多了。代理池新手先别碰，又费钱又麻烦，先把请求频率降下来、加上随机延迟再说。实在不行就上playwrig

你这情况我遇到过，大概率是vLLM的prefix caching加上Agent多轮拼接导致的。每次tool call返回后整个对话历史重新prefill，虽然token数不多，但KV cache会按最大序列长度预留，显存就慢慢吃满了。建议先关掉enable_prefix_caching试试，或者把max_num_seqs调小一点。另外检查下是不是每次请求都新开了session没复用，Agent框架

换Embedding模型基本等于换了一套语义空间，Chroma里存的向量跟新模型根本不在一个坐标系，检索能不崩吗？得把整个库重新embed一遍才行。另外BGE系列建议加query instruction，就是检索前给query加个"为这个句子生成表示用于检索相关文章"的前缀，不加的话效果差挺多的。混合检索确实值得试，BM25兜底关键词匹配能救回不少语义漂移的情况。

代码生成本来就不该靠堆示例，复杂逻辑拆小步让模型逐步推理更稳。你试试先让它列实现计划再写码。

说实话你这规模几十篇文档，几秒延迟八成不是chunk_size的锅，更像是embedding和检索链路本身没优化。我之前用Chroma也踩过坑，试试把文档按段落或者语义边界切，别死磕固定token数，再把top_k降到3左右配合MMR去重，效果会明显好一截。 另外rerank真不是奢侈品，哪怕用个很小的cross-encoder模型，都能把相关片段质量拉上来，省得LLM瞎猜。轻量向量库的话，小数

State这块我踩坑挺深的，建议把短期对话上下文和长期用户画像拆成两个独立State，用TypedDict加必填字段约束，别图省事全塞一起。MemorySaver确实只适合会话内，长期记忆我直接接的Redis存结构化数据，按用户id拉取再注入节点。子图传递我习惯只用显式传参，不共享父State，这样每个子图逻辑能自包含，测试也好写。你可以看看LangChain官方那个multi-agent例子，或