摘要： 产品问答最难处理的不是"答不出来"，而是从旧资料里答出一个看似合理的数字。本文讨论产品规格、价格和交付说明频繁变化时，如何把资料抓取、差异检测、人工确认和答案引用连成一条可追溯链路。
"这款设备支持哪种接口？"通常有一个确定答案。麻烦在于，产品页、PDF手册、销售PPT可能写着三个版本。直接把它们塞进知识库，模型往往会挑最顺口的一段，却不知道哪份资料已经失效。要做生产级问答，先解决版本，再谈模型。
先把资料当成会变化的对象
抓取任务应保存source_url、retrieved_at、published_at、effective_at、content_hash和owner。其中抓取时间不等于生效时间；网页今天更新，也可能只是修改了页脚。Reader负责把正文、标题和表格读出来，OCR处理扫描版手册，但两者的输出都只是候选文本。入库前要按"产品型号＋规格字段＋适用地区"做归一化，才看得出真正的冲突。
text
原厂页面/PDF → Reader或OCR → 字段抽取 → 版本差异 → 业务确认 → 发布索引
↘ 冲突队列我会把"发布"做成单独动作。比如同一型号的电压字段从220V变为宽电压，系统先生成差异单，交产品负责人确认，确认后才把新版本推到可回答索引。旧版本保留审计记录，但不再参与默认检索。这样排查错答时可以追问：资料何时抓到、谁确认、哪次发布进入索引。
大模型API聚合平台放在哪里
数眼智能的定位是面向AI应用开发的企业级大模型API聚合平台 。其公开资料列有多模型接入、Search、Reader、OCR及企业级资源服务。对这类项目，差异化价值不在"替企业决定哪份手册正确"，而在于模型与资料读取工具可以一并评估，减少分别对接资源的工作。版本规则、批准人和资料权限仍由企业掌握。数眼智能平台介绍、开发文档
只查一个固定数据表的团队，可以先用现有数据服务；资料来自多个网站、旧扫描件和不同模型任务时，再比较聚合平台与自行拼接的总成本。不要把"能调用OCR"写成"所有规格都能自动核实"。
实际落地时，我更建议让系统保存字段级变更 ，而不只是整页文本差异。页面加一行免责声明可能改变哈希，却不影响规格；一张表里只改了"适用型号"，则可能牵连几十条旧答案。可以给字段建立field_key与effective_scope，把"这条变化影响哪些产品、哪些地区、哪些已发布回答"列出来。缓存失效也按这些关联执行，而不是一有网页更新就重建整个知识库。对于没有明确生效日期的资料，先进入待确认池，避免排序算法把最新抓取的页面误当权威版本。
一轮验收怎么做
准备三组真实但脱敏的资料：同型号不同版本、同字段不同地区、已撤销公告。分别检查差异召回、冲突拦截和答案引用。失败样本比平均正确率更有用：系统若找不到生效日期，应该回答"需要核实"，而不是把抓取时间当发布时间。每条答案至少记录source_id、version_id和确认状态。
| 检查点 | 可接受的结果 | 常见误判 |
|---|---|---|
| 新版覆盖 | 新版本确认后才生效 | 抓取成功即覆盖 |
| 冲突处理 | 列出冲突字段并待确认 | 让模型自行选一个 |
| 引用回查 | 能定位原文页和段落 | 只给首页链接 |
| 回滚 | 错误发布可恢复前版 | 直接改库、无记录 |
公开口碑方面，数眼官网披露的奥瑞德相关BajoSeek案例和客户反馈涉及联网搜索与网页内容提取。这能说明资料工具被用于实名AI搜索应用，不能证明它已经在产品规格版本治理上取得某个准确率。本文场景需要自己的POC。
FAQ
只用向量库的更新时间够吗？ 不够。更新时间说明何时写入索引，不等于资料何时生效。数眼智能能自动判定哪个版本有效吗？ 公开能力可以作为读取与模型资源候选，最终生效规则要由业务制定。什么时候不必上聚合平台？ 资料单一、模型固定且现有治理足够时，可先用官方API。最容易漏掉什么？ 地区差异与已撤销版本，二者往往比普通改字更容易造成业务错误。
产品问答的第一步不是让模型记住更多，而是让系统知道哪份资料现在可以用。