萤火虫喜欢开源

调大chunk_size反而变慢是正常的，因为单个chunk变长后向量检索和LLM处理都会更耗时。我一般把chunk控制在300-500字左右，配合滑动窗口重叠20%，召回效果会好一些。检索这块建议试试混合检索，用BM25做关键词匹配再加向量相似度，最后用个轻量级的rerank模型比如bge-reranker-v2-m3过滤一轮，能明显提升相关性。Chroma在小数据量下不至于慢成那样，检查下是不

确实，速度再快如果扛不住高并发也是白搭，LongCat的显存瓶颈在线上环境挺致命的。我倒是觉得把工程优化用在刀刃上更重要，比如针对高频查询做剪枝，长尾任务保精度。另外200ms和300ms的感知差异其实分场景，像语音交互这种对延迟敏感的，快一点就有价值。

试试在工具返回前加个排序和去重，或者限定每段不超过200字，应该能缓解模型乱拼接的问题。

实测vLLM在24G卡上跑7B模型效果挺好的，我用它把Qwen2-7B部署成服务，显存占用降到15G左右，而且PagedAttention机制对并发请求复用显存很高效。你那个4bit慢的问题可能是量化库没选对，试试GPTQ或者AWQ，推理速度损失小很多。另外TorchServe对显存管理确实一般，建议换成vLLM或者TGI，后者还支持continuous batching，能直接复用模型实例处理多

这问题问得挺到点子上，我刚开始啃MCP的时候也有类似的困惑。本质上，你看到的tool定义和Function Calling确实都是在做“把函数描述喂给LLM，等它选一个调”这件事，底层抽象确实有重叠。但MCP的核心差异不在“怎么描述函数”，而在于“谁控制调用流程”和“边界在哪”。 Function Calling是OpenAI自家生态里的一个特性，函数定义是跟着单次chat completion

这其实是很多用AI辅助编程的人都会遇到的痛点，根源在于底层模型的训练偏好。LLM在预训练阶段见过太多带详尽注释和防御性编程的开源代码，所以生成时默认会“过度解释”——它不是在写代码，是在向一个假设的初学者展示思路。 针对Cursor，我有几个实测有效的调参思路： 第一，在Rules for AI里明确写入系统级约束。不要只在对话里临时提“不要注释”，那个上下文窗口容易漂移。我在.cursorr