#RAG

用向量数据库做了个知识库,踩了几个坑

由@ginkgo发起讨论 · 发布于 2026年8月1日 · 更新于 2026年8月3日

给公司搭内部知识库,选了个专用向量库,用下来踩坑不少。

一是维度选择一开始瞎选,后来才知道要和 embedding 模型对齐;二是索引构建巨慢,几万条数据等了好久;三是"召回快但召回不准",调了好几天 HNSW 的参数。

最坑的是换 embedding 模型后所有向量得重新生成,数据库直接废一半。早知道先小规模验证了。大家的向量库都怎么选的?

回复

暂时没有回复。

Related

相关推荐

讨论

一个 MCP + RAG 的小组合

做了个小工具:把内部文档向量化存好,然后用一个 MCP server 暴露"检索文档"这个工具给 Agent。Agent 回答问题时会自动调这个工具查文档,效果比纯 RAG 好。 原因是 Agent 能判断"要不要查""查什么""查到的够不够",而不是无脑检索拼接。相当于 RAG

讨论

你现在主力调哪家的大模型 API?

我做应用基本离不开 API 调用了,以前是某一家死忠,最近半年纷纷转向多供应商。原因一是价格战打起来,二是各家各有擅长,三是怕单一供应商出故障全盘崩。 我现在主力推理用一家,工具调用用另一家,便宜路由用开源小模型,靠一个统一网关切换。 缺点是不同模型行为差异大,prompt 经常

讨论

RAG 值得学吗?长上下文会不会把它淘汰

每次看到"上下文又翻倍"的新闻,都有人喊"RAG 要死了"。但我学了一阵子 RAG 之后觉得,这说法太夸张。 长上下文确实能塞下更多原文,但贵、慢、而且模型对超长上下文的"中间遗忘"问题还在。RAG 的优势是精准召回 + 成本可控 + 可追溯来源,这些是长上下文替代不了的。 我的

讨论

求助:RAG 检索出来的 chunk 总是不相关

搭了个 RAG,文档塞了几百篇,但检索效果很差,top 5 里经常只有一两条相关,甚至完全不沾边。embedding 用的也是主流模型,不知道哪出了问题。 怀疑过几个点:chunk 切太大(一段塞了多个主题)、问题太短召回不上、或者文档本身噪音多。 排查了一周没头绪。大家有没有