1.1GB的搜索模型只查一次网，编造答案从10%降到0

它不聊天，只查一次

Obsessive-1.7B 是一个 1.1GB 的网页搜索子代理，基于 LFM3-1.7B 微调。它只干一件事。接一个事实性问题，调用一次 web_search，返回简短答案、逐字引用和 URL。搜索结果里没有答案，它就输出 “Not found in the search results.”

它跑在更大的模型下面，不负责聊天。作者说，基础模型 LFM3-1.7B 在工具调用和信息提取上的表现让他意外。后面这些成绩，多少都能看到这一点：一个 1.7B 的模型被压到只做一件事，反而稳。

固定测试：编造从 10% 降到 0

固定结果基准用的是 131 个保留的 SimpleQA 问题。其中 29 个问题的答案被拿掉，专门制造“查不到”的情形。

答案在的时候，基础模型找到 50%，Obsessive 找到 94%。答案不在的时候，基础模型 0% 会说没找到，Obsessive 是 100%。编造答案，基础模型 10%，Obsessive 0%。在 4060 笔记本上，中位回答时间从 5.1 秒降到 2.0 秒。

命中率接近翻倍，耗时少了六成，编造归零。这三件事同时发生，比任何单项数字都难做到。

实时测试：回话率 100%，正确数更少

实时测试换了维基百科搜索后端，这个后端模型训练时没见过。题库是 120 个问题加 40 个多事实请求。

Obsessive 100% 给出回复，基础模型 38%。40 个多事实请求，Obsessive 全部作答，基础模型只答了 1 个。编造事实值这项，基础模型 4 个样本全编，Obsessive 是 52 个里 3 个。

正确数反过来：120 个问题里基础模型对 37 个，Obsessive 对 24 个。原因不对称。基础模型会一直搜下去，回复写得长，答案更容易冒出来。代价是有 62% 的情况耗尽轮次，返回一片空白。Obsessive 只搜一次，只陈述能逐字引用的内容。

两边交换的是失败方式：一边什么都没返回，一边漏掉本来能答的题。基础模型原始正确率更高，但有六成多的提问彻底没回应；Obsessive 几乎每次都回话，代价是漏检更多。

已知的毛病

每个对话只能问一个问题。多轮对话会把它搞混，训练数据全是单问题，作者把部分原因归到训练时的显存限制。

它会把声明当事实。“X 说它解决了 Y”，可能被它输出成 “Yes”。大约十分之一的答案其实就在搜索结果里，它却报“没找到”。有时还会引用相邻的事实，比如问某年的冠军，它引了另一年的。另外只支持英文。

报“没找到”这条和“从不编造”是同一个取舍的两面：只搜一次、只引用能逐字核对的内容，宁可漏，不肯猜。

训练成本：一张 4060 笔记本

LoRA rank 16，约 9k 条工具调用对话，训练在 RTX 4060 笔记本上完成。数据来自维基百科和 FineWeb 页面，每个答案和引用都核对过是否逐字出现。大约四分之一的数据专门教它说 “not found”。本地的 qwen 3.8 flash next 也帮忙准备了训练数据和问题。

运行就一行：llama-server -hf banyohavlusu23/Obsessive-1.7B-GGUF --jinja -c 16384，温度设 0。仓库里有 Pi、OpenCode 和 Hermes 的配置，外加一个不需要密钥的 Python 脚本。模型以 GGUF 格式发在 Hugging Face 上，作者修正过一次失效链接。许可证继承自基础模型的 LFM 开放许可证。是否允许商业使用，发布说明没有交代。

评论区的几个问题

u/a4mula 认为，搜索代理眼下最大的威胁是模型把数据当指令。它出去找数据，找到的却是能改变它行为的指令。u/MajesticPuzzler 也觉得搜索结果里藏指令的风险被低估。他同时问作者怎么给“弃答”打分：区分“这批结果里没有”和“确实不存在”。

另一个问题是漏检的边界。u/AshRuDral_fan17 问它在判定 “not found” 之前会翻多少页搜索结果。模型只调用一次搜索，所以这个问题实际问的是：那一次搜索能带回多少条结果。

也有人给替代思路。u/shing3232 平时用 4b 的 qwen3.5 微调模型做搜索和小任务。u/Gotxi 用 MiniCPM5-2B-Q4_K_M 跑在内存和 CPU 上，因为显存被大模型占着。u/DHTechdev 建议让它标记多部分问题、要求提问者缩小范围，而不是硬答整题。

作者欢迎反馈，尤其想要失败案例。u/hidden2u 问微调花了多长时间，u/cleverusernametry 问有没有日常用过，两个都没有答复。实时测试只跑过维基百科这一个后端，其他网站上的表现目前不清楚。