刚入门的算法人手记

这个坑我踩过，而且比你想的还麻烦。Chroma本身不负责语义去重，你存进去啥它就给你啥，所以关键得在自己那层加逻辑。哈希去重只能干掉完全一样的文本，像“订单号多少”和“我单号是啥”这种换个说法的根本没用，实际场景里几乎等于白给。相似度阈值我倒试过，把cosine距离设个0.9左右做近邻检测，命中就更新旧记录的时间戳而不是插新条目，效果还行，但阈值调低了会误合并，调高了又漏去重，得拿自己业务数据慢慢

A100 40G跑7B还这么慢，感觉瓶颈大概率不在显存也不在量化上。你可以先看下nvidia-smi里GPU利用率是不是一直上不去，再确认下是不是被默认的max_model_len拖累了，vLLM会按最长序列预分配KV cache，有时候反而限制并发。BF16换FP8对7B来说收益有限，先别急着换框架，用vLLM自带的benchmark脚本压一下，看TTFT和TPOT具体卡在哪一步更靠谱。

这个现象其实挺常见的，torch.compile默认模式确实会为了图优化保留一些额外的中间结果，尤其是你这种带反向传播的训练场景，显存涨个20%-30%不奇怪。我这边跑7B模型的时候也遇到过类似情况，后来发现跟dynamic shape关系很大，如果你attention那边有变长序列或者用了padding，它可能会反复触发重新编译，同时缓存一堆不同shape的计算图，显存就炸了。你可以先试试加`d

我也经历过这个阶段，说实话那种“跑通了但讲不清为什么”的感觉比写不出来还难受。后来我逼自己做了件事：凡是AI生成的代码，尤其是涉及并发和状态流转的，我必须用注释把每一步的意图写出来，写不出来就说明我没真懂。状态机这种玩意AI给的实现经常是能跑但边界条件含糊，你不自己画一遍状态转移图根本发现不了坑。我的建议是别走极端，CRUD继续让AI写没毛病，但核心模块刻意先手写骨架，再让AI补细节，顺序反过来效

本质区别其实在自动求导的图机制上。TF的静态图是先建图再执行，所以需要@tf.function把Python代码trace成图，而PyTorch的动态图是边跑边建，每次forward都重新构建计算图，灵活但理论上有些开销。Tensor本身的内存布局倒是差不多，都是连续内存块加strides，转换时to numpy一般共享内存，但numpy转回tf就得看情况了，tf.convert_to_tenso

先写测试这招我试过，确实管用，让它按测试用例来写比空口描述边界靠谱多了。

Python SDK就够用了，你们这个并发量和数据规模根本喂不饱性能瓶颈，TS版本快那点差距在实际场景里基本感知不到。我自己用官方Python SDK搭过类似的本地知识库，几千条文本检索加生成，响应完全没问题，部署也省心。真正要纠结的其实是你的Agent框架后续怎么接，MCP本身是协议层的东西，跟Server用什么语言实现关系不大，重点看哪边社区维护更活跃、文档更新更勤。如果团队本身Python技

阈值0.85确实容易误伤，我之前也踩过这坑。后来把检索改成两路并行，一路纯向量相似度，另一路按时间衰减给近期对话加权，最后用RRF融合排序，效果比单一阈值稳很多。另外建议检查下chunk是不是太粗了，比如把整个回答切成一块，很容易把话题带偏，按语义断句切成小段试试。

哎，同感，我拿Qwen2.5跑过几个跨模块的活儿，也是这个德行。单文件是真的快，但一牵扯到外部依赖，它就爱自己脑补接口，我一度怀疑是不是我AWQ量化压太狠了。后来干脆把相关函数定义和调用点都拆成小块，分次喂进去，每次只让它改一小步，反而稳不少，虽然费点token但至少不用回头debug到崩溃。

试试把每个工具的使用场景和前置条件写成强制校验规则，比如发邮件前必须确认查询结果非空。另外ReAct对长链路确实容易飘，可以切plan-and-execute模式先拆解步骤。

你这情况多半是chunk边界切碎了语义，先试试带overlap的父子分块，再不行就上rerank卡top3。

我最近也折腾过这个，试下来感觉你第一种做法的问题在于示例里没有context字段，模型会把few-shot当成纯问答对，自然就忽略检索内容了。我现在的做法是示例里同时带query和一段简短的context摘要，但context故意写得比较泛，比如“根据产品文档，保修期通常在1-3年不等”，这样模型既能学会格式，又不会死板套用具体数字。你可以试试把示例里的答案写得更依赖上下文推理，而不是直接给结论，

这问题太典型了，我上线那会儿也踩过。Top-5召回有货但生成不用，大概率是chunk切太碎导致上下文丢了，比如报销和请假流程写在同一段里被切断。先试试把chunk调大到300-500字，或者加个滑动窗口重叠，看生成有没有改善。另外你prompt里得明确告诉模型“优先基于检索到的内容回答，如果内容不相关就说不知道”，不然模型容易自己脑补。要是还不行，再考虑rerank，但别一上来就换模型，成本高。

base64塞JSON这个路子我试过，图片稍微大点直接爆延迟，后来改成先把数据推到S3或者MinIO，MCP里只传对象引用和预签名URL，模型那边直接从存储拉，体感好了不少。不过你这个场景如果走Triton，其实可以试试在MCP server里只做协议转换，真正推理丢给Triton的HTTP/gRPC接口，自己别碰tensor，这样数据流干净很多。我见过有人直接在MCP server里内嵌模型，小

说实话7B模型跟在线API的差距主要不在量化，Q4_K_M影响没那么大，核心还是模型参数量级摆在那，指令遵循能力天然弱一截。我自己试过把任务拆成两步走，先让模型列大纲再让它扩写，比直接给完整prompt稳很多。另外系统提示词里别光强调角色，试试给一个具体到标点符号的输出模板，它会老实很多。温度我个人觉得0.3左右比直接拉最低效果好，太低了反而容易机械重复。

元数据过滤肯定要加，不然纯靠向量就是瞎蒙，标签成本其实不高，写脚本批量搞一下就行。 试试混合检索，向量召回后加一层关键词硬过滤，比调阈值靠谱多了。

fp16震荡大概率是loss缩放没调好，试试bf16或者给pad设mask，A100跑7B不该爆的。

建议先给接口文档和依赖库版本，再让它分步写，一次别超过30行代码，能少一半幻觉。 温度参数调低点管用，但更关键的是把报错直接甩给它，教它迭代改。

固定512切确实容易把语义切碎，试试按标题层级先分段，再对长段用递归切分。

检索这步大概率就漏了，试试把query做意图改写再召回，别直接拿原文去怼向量库。