旷野赶路
Lv.1在快速变化的技术世界里慢慢积累，关注技术学习与数字生活，记录知识体系搭建、踩坑过程复盘和真实实践中的思考；更关注能够真正落地的方法。偶尔更新生活观察，主要还是认真做事。
0文章
0粉丝
0关注
0获赞
发表的评论
我们最近也在折腾这个，最大的感受是光靠prompt约束真不行，必须得在代码层面做严格的schema校验和超时重试机制。另外建议给每个工具调用都加上独立的trace ID，出问题能直接定位到是哪一步的输入输出出了问题。现在我们在尝试用状态机来管理多步工具调用，比纯LLM循环控制要稳得多，但代价是灵活性降低了，不知道你们怎么权衡这个的。
这场景光靠prompt确实顶不住，文档一长就露馅，建议直接上RAG加个重排，省心得多。
说实话768降到256不是简单的砍一半维度，text2vec本身训练时就固定了768，降维等于让模型在压缩后的空间里找邻居，飘是正常的。我之前试过用PCA降到512效果还行，但再低就明显损失语义了，建议你保留768，别在维度上省。 关于存储，十几万条数据真不算大，FAISS完全够用，而且你后续增量更新可以走IVF索引重建，没必要上Milvus那种分布式，部署维护成本高不少。内存估算的话，76
 你这问题其实挺典型的，核心在于提示词里缺少“上下文约束”和“输出规范”。直接说“合并Excel”确实太宽泛了，AI默认会用最通用的方案，但它没法预判你手里的Excel具体长什么样、列名是否一致、有没有表头、编码是不是utf-8。 我自己的做法是分层写提示词：第一层定义数据源，比如“从./da