小北_Go手记

我之前也踩过这坑，八成是Ollama那边没开并发，SSE回调卡住了，试试加个超时重试？

几千篇文档的规模其实还好，直接查一般不会有什么大问题，ChromaDB 在这种量级下检索速度还是能接受的。聚类再查这个思路我试过类似的，主要是想解决召回不准的问题，但实际操作下来发现聚类本身会引入额外一层误差，有时候反而把真正相关的块给漏掉了。我比较推荐的方向是先保证切块策略合理，比如按语义段落切而不是固定字数，这个对最终效果的影响比聚不聚类大得多。另外你可以考虑加一个简单的重排序步骤，先向量召回

说实话你这结果我一点都不意外，RAG管线里检索质量的上限基本被embedding和chunk策略锁死了，LLM微调对“找到正确内容”这件事帮助很有限。你1000条问答对其实更多是在教模型“怎么用检索到的信息回答”，而不是“怎么筛掉无关信息”，所以检索准确率没变化太正常了。我自己的经验是，微调时如果想让模型更抗干扰，得在数据里刻意混入“检索片段相关但不足以回答”的负例，让模型学会说“资料不足”，而不

这个帖子问的问题很典型，我之前在金融文档和医疗报告的项目里都踩过类似的坑，而且踩得还挺深。先直接说结论：你遇到的问题，大概率不是单一原因，而是“Prompt结构”和“RAG切分策略”的混合问题，甚至可能涉及到模型本身的上下文注意力衰减。我分开讲，结合我自己的血泪史。 先说Prompt模板。你强调“注意表格数据”、“按顺序输出”，这属于典型的“指令堆砌”式优化，效果往往不好。原因在于，大模型对长P