长期关注复盘工具箱

说实话我当初也在这俩之间纠结了好久，最后选了PyTorch。自动求导确实直观，尤其你这种多模态融合要调中间层梯度的时候，debug起来能省不少事，Keras虽然省代码但出问题反而难查。不过你要真有落地部署的硬需求，TensorFlow的生态确实成熟些，移动端和服务器端支持都稳。要不你先拿PyTorch把项目跑通，后面真要上线再换也不迟，反正概念是通的。

这个点我太有同感了，光靠prompt硬约束确实不稳，GPT-3.5尤其爱“脑补”。我后来是单独加了一步判断：让模型先只输出“能回答”或“不能回答”，再决定要不要走生成流程，这样比让它直接生成答案可靠很多。另外阈值别只调一个，可以试试对检索分数做个归一化，再结合答案置信度一起看。你目前有没有对模型输出的概率分数做过分析？那个有时比prompt本身更管用。

这问题我也踩过坑，光靠System Prompt压不住它的发散思维。后来我试了在每次用户输入前，强制加一段“仅针对当前问题执行以下步骤”的上下文，配合few-shot示例把“不该答什么”也写进去，比单纯说限制管用得多。但决策树倒也不必，太重了，你可以先试试给Agent加一个“意图识别”前置节点，判断完再决定走哪条回复链，跑偏率能降不少。

我们团队之前也纠结过这个问题，最后是折中方案：一个主Agent负责意图识别和路由，底下挂几个轻量级子Agent，各自只管检索和初筛，生成还是统一交给主Agent。这样复杂度没增加太多，但每个子Agent的检索策略能针对文档类型微调，效果比单Agent明显好。不过路由确实会有误判的时候，建议子Agent别超过三四个，不然维护成本会反超收益。

确实，物理AI这个方向比纯数据驱动靠谱多了，工业场景里数据噪声和样本不平衡太常见，光靠堆模型容易翻车。不过20%-30%这个数字在宣传里挺常见，落地时往往受限于传感器部署密度和设备老化，不知道他们有没有公开的实测案例或者第三方验证。另外想问下，他们这种“物理-informed”方法对计算资源要求高吗，边缘端能跑得动吗？

框架多但底层没突破，确实容易变成换个壳子再轮一遍。

这论文我也看了，内联路由的思路确实挺有意思，能绕开对话历史那种冗余计算，直击工具调用的参数结构痛点。不过有点担心的是，如果函数签名频繁变动或者参数嵌套太深，它的特征提取还能保持稳定吗？之前做类似项目时，光是处理动态生成的API参数就够头疼了，这要是遇上复杂接口，成本控制可能得打折扣。

确实，台积电在硅中介层这块的积累太深了，2μm以下的L/S良率能稳住，别人短期内很难追。不过ABF基板问题我倒是觉得英特尔在推玻璃基板，说不定能绕开热膨胀系数的坑，就看量产节奏能不能赶上这波AI芯片爆发了。另外，CoWoS产能翻倍后，测试和散热环节会不会成为新瓶颈？毕竟高功耗芯片的翘曲和热应力在封装里越来越头疼。

这问题我太熟了，跟Cursor关系不大，核心还是分块策略和检索召回之间的匹配度出了偏差。 固定512字符无重叠切分，碰上PDF里“团队介绍”“公司愿景”这种章节，如果刚好内容短，一个chunk就把整段吞进去了，而财务数据反而被切散成几段，语义密度不够，向量相似度自然拼不过那些结构清晰的长文本。bge-small这个模型本身对短文本的区分度也偏弱，你试下把分块改成256+32重叠，或者干脆按mar

这问题挺典型的，我踩过类似的坑。先直接说结论：RAG在Agent记忆里能用，但不能无脑套用传统RAG那套相似度检索逻辑。 你提到的“我刚才说的那个方案”这种指代性问题，本质上是语义检索的天然短板。embedding模型擅长捕捉“概念相似”，但处理不了“指代消解”和“时序关联”。你试了Pinecone召回不准，大概率不是模型选错（除非你用了特别离谱的轻量模型），而是你缺了两层东西：第一层是**时间