持续研究品牌随身笔记

我之前也在这个问题上折腾了很久，后来发现光看token数其实不够，得结合文档的实际结构来定。技术手册这种文档，标题层级和代码块边界比固定token数重要多了，我现在的做法是用MarkdownHeaderTextSplitter先按标题切，再对超长段落做二次切分，效果比一刀切好不少。overlap的话我一般设成chunk的10%到15%，太小了跨块的上下文接不上，太大了检索结果重复率高得离谱。另外你

我也遇到过类似情况，感觉角色设定有时候会把模型带偏，让它太想“演好这个角色”反而忽略了任务本身。尤其是那种带职业身份的，模型会脑补一堆该角色该说的话，摘要就不老实了。我现在一般只在需要特定语气时才加角色，纯任务型的基本裸跑，效果反而干净。

几万条数据其实Milvus有点重了，etcd加minio那套维护起来确实烦。我之前类似场景换成了Qdrant，单机docker跑起来很省心，召回也比Chroma稳不少。不过召回率差有时候不全是向量库的锅，切片策略和embedding模型影响更大，可以先把这块调一调再决定换不换。

我一般Buffer加Summary混着用，近期原文留着，老的压缩成摘要，省token还不丢关键信息。

微调数据里最好混入工具调用和返回结果的完整轨迹，光靠指令格式确实容易把Agent能力带偏。

我也这样，细节给太多它反而加戏，简单说需求出来的代码干净多了。

我最近也踩了差不多的坑，一开始觉得上下文给得越足模型越聪明，后来发现根本不是那么回事。尤其是把分支名、最近提交这类信息一股脑塞进system prompt之后，模型注意力明显被分散了，用户真正问的问题反而被挤到后面。我现在的做法是只保留跟当前任务强相关的字段，其他的用工具按需拉取，而不是预加载。另外模板里的few-shot示例确实容易被当成硬约束，我后来把示例改成“参考格式”并明确标注不是必须遵循

我踩过一模一样的坑，后来发现死循环大多不是框架问题，是工具描述和退出条件没写清楚。与其急着上LangGraph，不如先手动把分支逻辑和兜底策略跑通，知道每一步为啥这么走。Agent变聪明靠的是状态管理和失败后的降级设计，不是堆更多工具。

这问题太真实了，我试过在系统提示词里直接写“组件props严格遵循最小化原则，不得添加未明确要求的属性”，然后把常用组件接口文档贴进去，能好一点。不过说实话，Cursor对上下文的理解还是比人差远了，有时候你给它看一个现有组件的写法，它才会照着模仿，单靠嘴说确实不稳定。

说实话你这思路我踩过一模一样的坑，Qwen2.5的隐藏层输出本质上是为生成任务优化的，跟专门做语义匹配的embedding模型在特征分布上差别挺大，所以检索效果不稳定太正常了。池化和归一化确实会影响结果，但就算调好了也很难追上专门的embedding模型，毕竟人家训练目标就是拉近相似样本的距离。建议直接换bge-small或者gte-small这类轻量模型，几百MB跑本地完全够用，检索质量提升会非

1亿条768维这个量级，单机跑确实有点吃力了，但不是没救。你现在的核心问题大概率不是索引类型选错，而是内存带宽和CPU缓存命中率撞墙了，HNSW在超高维数据上构建图结构本身就吃内存，而且查询时随机访问内存的代价比IVF系列高不少。我个人建议先切回IVF_FLAT或者IVF_SQ8试试，SQ8能把内存砍掉四分之三，召回率损失在可接受范围，同时把nlist调成你数据量的平方根量级，nprobe从64开

试试把onnx的opset调到17以上，然后trt那边min/opt/max三个维度必须严格对应实际输入范围，我之前就是这么解决的。

这loss水平对7B代码模型挺正常，试试把alpha调成32或换带缩放基线的数据集看下。

试试把对话历史先做一轮意图压缩再拼接，能少很多噪音，或者直接看下MemGPT那套分层思路。

torch.compile对动态shape的支持其实比JIT好不少，它有专门的dynamic shape模式，但默认开启的话编译开销会摊薄到每次输入变化上，你可以试试把mode设成max-autotune或者限一下动态维度。自定义注意力掩码只要不是纯Python控制流，一般都能被graph break处理，顶多回退到eager，不会报错但加速效果会打折。我建议你先用torch.compile的pr

Qdrant上手快但集群扩容时坑不少，Milvus功能全可运维成本高，小团队慎选。 Milvus坑在依赖太多，部署起来头大；Qdrant单机性能不错，但中文文档少得可怜。

max_iterations设小点，输出格式锚死，再加个中间结果校验，跑偏概率能降不少。

说实话我觉得你现在的瓶颈大概率不在向量库本身，而是embedding和检索策略的问题。ChromaDB在几千篇文档的规模下性能不会差到哪去，准确率飘更多是分块方式或者向量模型对长文档语义捕捉不够。你可以先试试换更强的embedding模型，比如bge-m3或者e5-large，再配合混合检索（关键词+向量），说不定成本最低的提升就来了。 真要换库的话，Milvus单机版在Mac上跑起来其实没想象

混合召回对rerank延迟影响挺大的，建议先拿bge做主力，text2vec当候选补充，实测多路召回得加缓存。 单卡T4跑bge-large其实能接受，把分块调小点，速度能上来，召回率也比text2vec稳。

说实话我之前也卡在“AI只建议不执行”这个点上，后来发现MCP更像是个“读权限”的增强，真要让Cursor跑命令还得靠它内置的终端工具或者自定义agent，不是靠MCP本身。你连不上本地Node服务大概率是环境变量或者权限问题，试试把server跑成后台进程再让MCP走http协议，别用stdio模式，能省不少麻烦。至于自动修TS报错，我现在的做法是让AI先改代码，然后我手动触发一次tsc检查，完