AI

做混合检索时，会碰到一个很朴素的问题。 BM25 说某篇文档得了 18.6 分，向量检索说另一篇文档的相似度是 0.83。到底谁应该排在前面？ 18.6 看起来比 0.83 大得多，但这两个数字根本不在同一把尺子上。直接相加没有意义，随手归一化又会受到查询、模型和数据分布影响。 RRF 提供了一个很省心的思路。 既然各路分数不好比较，那就不比较分数，只比较排名。 为什么混合检索需要结果融合 关键词检索和向量检索擅长的事情并不一样。 BM25 根据词项出现情况计算相关性，遇到错误码、产品型号和专有名词时很有优势。查询里明确出现 ERR_CONNECTION_RESET，包含同一字符串的文档通常应该优先返回。 向量检索比较的是语义表示。用户问「服务突然连不上了怎么办」，即使文档里没有完全相同的句子，只写了「连接被远端重置」，它也有机会把内容召回。 两路结果放在一起，覆盖面通常比单一路径更好。麻烦在于，它们返回的原始分数没有统一含义。 BM25...

最近看 Agent 相关的项目，经常会同时碰到三个词，Function Calling、MCP 和 Skill。 它们看起来都和「让模型做事」有关，于是很容易混在一起。有人把 MCP 当成更高级的 Function Calling，也有人觉得有了 Skill 就不需要 MCP。 其实它们并不在同一层。 最简短的理解是，Function Calling 负责表达调用，MCP 负责接入能力，Skill 负责组织做事的方法。 一个让模型知道怎么开口，一个把工具接进来，一个告诉 Agent 事情应该怎么完成。 Function Calling 解决的是调用格式 大语言模型只能生成内容。哪怕它说自己要查询天气，也不会真的凭空发出网络请求。 应用需要先把可用函数的名称、用途和参数结构告诉模型。模型判断需要使用工具后，再返回一个结构化调用请求。宿主程序收到请求，执行真实函数，然后把结果放回对话。 一个简化后的工具定义可能长这样。 1234567891011{ "name": "get_weather", ...

大模型最麻烦的时刻，不是它说不知道。 而是它给出一个语气笃定、结构完整、甚至带着出处的答案，等你真的去查，才发现内容根本不存在。 这种现象通常被叫作幻觉。 模型不是在主观撒谎。它的核心任务是根据上下文预测接下来最可能出现的内容。当可靠信息不足时，它仍然可能生成语言上非常合理的答案。读起来顺，不等于事实正确。 所以减少幻觉，不能只靠一句「请不要胡编」。更有效的思路是让模型有依据可用，在依据不足时允许拒答，并让最终结论能够被检查。 普通使用时，先缩小回答空间 问题越开放，模型自由发挥的空间越大。 直接问「介绍一下这个项目」，模型可能自行补充作者、时间线和功能。把要求改成「只根据下面提供的...