清晨观星录

结构化输出确实容易崩，我一般把格式要求单独放最后一句，权重会高很多，长上下文就分段塞。 试试把任务拆成两步，先让模型判断风险再格式化输出，比一口气要JSON稳多了。

这问题我太有同感了，尤其是金融数值这种场景，模型一旦“跳步”你根本不知道它是真算对了还是蒙对了。我觉得核心问题不是提示词不够细，而是CoT本身对模型来说更像一个“文本生成模板”，它以为你在考它写步骤，而不是真的在约束它做算术。我之前试过把每一步的中间结果显式写进提示里，比如“毛利率=（收入-成本）/收入，现在已知收入是X，成本是Y，请先写出收入减成本的数值”，这样强制它输出那个数，断链概率会小很多

说实话你这个量级上pgvector真能再撑一阵，但别指望靠它做复杂过滤+排序，索引一多写入就难受。Milvus部署确实重，但你要是已经定了K8s路线，它的operator其实比Qdrant那个自带的更省心，升级和扩副本都自动化。内存这块Qdrant对纯向量更友好，但Milvus上了最新版用MMap模式压一压也差不太多。我个人经验是召回率这俩在同等参数下基本没差，真正拉开差距的是你embedding

切分策略确实和embedding模型要配合好，500的chunk_size对技术手册这种结构化文档可能太碎了，试试按章节或段落语义切分，别死磕固定长度。召回不准大概率是embedding模型对专业术语理解不够，换bge或e5这种专门调过的模型效果会好很多。reranker肯定要加，但别一上来就上，先把切分和embedding调稳了，不然reranker也救不了。另外可以试试query改写，用户问“

说实话这太真实了，我也经常遇到这种“半成品”代码。我觉得核心问题在于单次Prompt很难覆盖所有边界，尤其Python这种对异常和类型敏感的语言。我的经验是把大任务拆成小步骤，先让GPT生成骨架，再针对报错的地方单独补Prompt，比如“这个函数如果sheet为空怎么处理”，迭代几次反而比一次性要求更靠谱。