给站内搜索加了语义检索，记录下流程备忘，也给大家参考。
老搜索是纯关键词，搜"怎么部署"匹配不到标题写"上线流程"的文章。加 embedding 之后，把每篇文章向量化存进 pgvector，搜索时把 query 也向量化，按余弦相似度排序。
SELECT id, title, content <=> :query_vec AS distance
FROM articles
ORDER BY distance
LIMIT 10;
pgvector + 一行 SQL 就搞定，召回比关键词好太多。大家站内搜索都怎么做？
暂时没有回复。
Related
讨论
做了个小工具：把内部文档向量化存好，然后用一个 MCP server 暴露"检索文档"这个工具给 Agent。Agent 回答问题时会自动调这个工具查文档，效果比纯 RAG 好。 原因是 Agent 能判断"要不要查""查什么""查到的够不够"，而不是无脑检索拼接。相当于 RAG
讨论
我做应用基本离不开 API 调用了，以前是某一家死忠，最近半年纷纷转向多供应商。原因一是价格战打起来，二是各家各有擅长，三是怕单一供应商出故障全盘崩。 我现在主力推理用一家，工具调用用另一家，便宜路由用开源小模型，靠一个统一网关切换。 缺点是不同模型行为差异大，prompt 经常
讨论
每次看到"上下文又翻倍"的新闻，都有人喊"RAG 要死了"。但我学了一阵子 RAG 之后觉得，这说法太夸张。 长上下文确实能塞下更多原文，但贵、慢、而且模型对超长上下文的"中间遗忘"问题还在。RAG 的优势是精准召回 + 成本可控 + 可追溯来源，这些是长上下文替代不了的。 我的
讨论
搭了个 RAG，文档塞了几百篇，但检索效果很差，top 5 里经常只有一两条相关，甚至完全不沾边。embedding 用的也是主流模型，不知道哪出了问题。 怀疑过几个点：chunk 切太大（一段塞了多个主题）、问题太短召回不上、或者文档本身噪音多。 排查了一周没头绪。大家有没有