认真Python玩家手记

我一般把约束写进.cursorrules那种独立文件，每轮让它先读一遍，比塞system prompt管用。

我们之前也踩过这个坑，后来发现与其纠结固定字符数，不如先看文档结构。技术文档有标题、段落、代码块，天然就有语义边界，硬按字符切反而把逻辑切断了。我们现在的做法是优先按Markdown标题和段落切，超长段落再用递归切分，chunk size设成512但允许一定浮动，效果比死磕一个数字好很多。闲聊类文本确实不一样，句子短、信息密度低，切太小反而每段都没啥可检索的，得适当放大到800甚至1000。另外检

冲突这块我踩过坑，后来改成写入前先让LLM做一次事实提取，跟已有记忆比对，冲突的直接更新而不是新增，省得越堆越乱。遗忘我倒觉得不一定非要删，可以搞个冷热分层，近期高频的放小库精排，老的压缩成摘要丢大库兜底。Chroma本身不太适合做这种动态淘汰，可以考虑换Milvus或者Pgvector加个时间戳字段自己控。

负样本一定要加，不然模型会过度倾向调工具，遇到闲聊或简单问题也硬调，反而更乱。我试过大概掺20%不需要调用工具的样本，参数格式错误率降了不少。另外你检查下训练数据里工具调用的参数是不是真的严格对齐schema，2k条里要是有几百条格式飘了，模型学歪很正常。rank和alpha别光调，先把学习率降一点、epoch控制在2-3试试，7B在工具调用上SFT灌太多容易过拟合。prompt工程也要配合，推理

用向量库存历史周报，每次按项目名检索召回，比硬塞system prompt靠谱多了。

我们小团队用Qdrant跑了半年多，单机部署确实省心，Rust写的性能也够用，但它的分布式版本得用商业授权，集群这块基本别想白嫖。Milvus功能全，生态也大，可一套依赖下来etcd、MinIO、Pulsar，运维成本真不是小团队扛得住的，之前升级还踩过元数据不兼容的坑。如果数据量没到亿级，Qdrant单机加好索引其实挺香，上规模再考虑Milvus吧。

20万条128维其实不算大，FAISS崩多半是并发时多个请求同时打满CPU，跟索引类型也有关系，可以试试换IVF或者HNSW再压测看看。我之前也纠结过Milvus，后来发现Qdrant单机docker跑起来意外地轻，配置比想象中简单，维护成本没那么吓人。你说的加队列和缓存这思路没错，但缓存命中率不高的话治标不治本，队列只是把压力往后拖。如果就自己维护又不想折腾，其实可以先用Qdrant顶一阵，真到

metadata 得用字符串键值对，type 写成 object 容易丢，我之前也踩过这坑。

用response_format={"type":"json_object"}会稳很多，再配function calling基本不炸。

微调时模型没学过带检索上下文的样本，它当然不知道怎么用。建议把检索片段拼进训练数据重训一版。

LoRA rank先别动，2万条短文本batch=1加累积8够用了，震荡可能是学习率太高。验证集我一般500步看一次。

92.3掉到88确实有点夸张了，一般导出顶多差个零点几。建议先排查下预处理和后处理是不是对齐了，比如归一化参数、resize方式、还有输出有没有过softmax，这些坑比算子本身更常见。BatchNorm和AdaptiveAvgPool在opset11下基本不会有明显精度损失，你可以逐层对比下ONNX和PyTorch的输出，定位到具体哪一层开始偏的。另外移动端部署不一定非得TFLite，ONNX

按标题层级切确实靠谱，代码块和表格最好单独拎出来别混切，不然语义肯定散。

这问题我也踩过，ReAct里那个判断步骤光靠prompt确实很难稳定区分“没提”和“不知道”。我的做法是在prompt里加一个显式的三分类：已知信息、可推断、必须查系统，然后给每类写一两个few-shot例子，效果比单纯描述好不少。另外你可以把“用户没提”当成缺槽位处理，让模型先输出缺失字段再决定要不要调接口。纯靠一句“判断是否需要拉数据”太模糊了，模型很容易脑补。

记忆持久化确实是机器人落地的关键，光靠单任务Demo撑不起真实场景。不过展会现场那种嘈杂环境对感知和记忆的干扰很大，Moz2要是能扛住多轮打断和重定向，那才算真本事。我更好奇它的记忆是存在本地还是云端，如果是云端，延迟和隐私怎么平衡？

试试把`--gpu-memory-utilization`往下调到0.85左右，再开`--enable-chunked-prefill`，vLLM默认会预分配一大块KV cache，并发一上来直接就顶满了。A10 24G跑7B其实不算宽裕，8192上下文本身就吃不少显存，三四个人同时进来很容易爆。另外可以看看是不是gradio那边没做好请求排队，一下子全丢给vLLM了，加个并发上限会稳很多。量化的

512的chunk对合同这种条款散落的文档确实太大了，试试换小到256再配合父子索引，召回准很多。

我一般会在prompt里明确要求“只根据检索内容回答，不要自己发挥”，再加一句“如果检索内容里没有相关信息就直接说不知道”，这样能压住瞎编的毛病。分点还是直接结论其实看场景，事实型问答直接给答案更干净，多跳推理才需要列点。温度我通常设0.1到0.3之间，太高了容易加戏。另外可以试试把检索片段标上序号，让它引用来源，这样它会更谨慎，不太敢乱编。

我之前也踩过这个坑，最后直接让所有client连同一个本地HTTP server，sqlite-vec换成WAL模式后并发读写基本没出过问题。多个server实例各写各的确实没救，除非你接受数据割裂。鉴权其实不用搞太复杂，绑127.0.0.1加个简单token就够本地用了。

我遇到过，多半是chunk切太碎导致上下文断了，先试试重叠切分加长一点。