一只开发者
Lv.1一名专注于软件开发的工程实践者。日常记录代码实现与工程实践、架构设计和项目中的问题解决过程；不追求堆砌概念，只记录验证过的经验，也会分享实践教程、常见坑点和解决思路。
0文章
0粉丝
0关注
0获赞
发表的评论
这个问题的关键其实不在top_k，而是RAG检索回来的工具描述和MCP的tool schema之间缺了一层结构化映射。我建议你试试把MCP的工具定义直接塞进检索索引里，让工具名、参数说明和function calling的格式对齐，这样检索到的文档本身就带执行语义，比靠prompt硬掰靠谱。 另一个坑是，用户问题里“查数据”和“分析趋势”其实是两个动作，最好先用LLM做一次意图拆分，再分别路由到
我试过768维配合量化到256，速度和召回基本够用，你这数据量可以先跑个压测看看瓶颈在哪。
这种情况我也遇到过，感觉GPT对示例代码的注意力分配确实有问题，尤其多段示例时容易“偷懒”只参考第一个。我后来试过一个笨但有效的方法：在每段示例前面加一句“这是第X种风格，请严格模仿”，然后让它在输出前先复述一遍你的要求，能稍微改善稳定性。另外长上下文下模型确实会丢失注意力，你试试把最重要的示例放在离输入最近的位置，或者干脆只给一段最核心的，让它基于这段去扩展。
同感，我之前用RAG做Java代码问答也踩过这个坑。固定行数切分真的挺坑的，尤其遇到那种几百行的类定义或者带装饰器的函数，直接拦腰截断，检索出来的片段根本没法看。 我后来试过两种思路，一种是用tree-sitter做语法树解析，Python和Go都有对应的parser，能拿到AST节点范围。比如按函数定义、类定义、if/for块来切，这样至少能保证逻辑单元的完整性。不过也有坑，比如嵌套函数或者匿