AI 问答库
一句话回答
重点看三件事：交付过什么、数据归谁、他走之后你能不能自己维护。要求对方拿出可访问的真实系统而不是 PPT 和演示视频；在合同里写清数据、模型权重、代码和微调产物的归属；把二期改动和故障响应的报价问在签约之前。至于用哪个模型、走 RAG 还是微调，反而是后期最容易换的部分，不该成为主要评估项。
把评估拆成可验证的问题，比看资质和案例数量有用得多。下面每一行都是可以在第一次技术交流里直接问出口的，对方的回答质量本身就是信息 —— 含糊、绕开、反复强调「我们技术很强」都是信号。
| 评估维度 | 该问的具体问题 | 危险信号 | 合格回答的样子 |
|---|---|---|---|
| 交付证据 | 能给我一个在跑的系统账号，让我自己点吗？ | 只有 PPT、剪辑过的视频、打码截图 | 给出可访问地址或现场演示未预设的操作 |
| 数据与资产归属 | 数据、微调后的权重、源码，合同里归谁？ | 回答「行业惯例都这样」但不肯写进条款 | 明确条款，并说明离场时如何交接与导出 |
| 可维护性 | 你们不参与后，我方工程师改一个提示词或加一类文档要怎么做？ | 所有改动都必须找原厂、按人天计费 | 有后台配置界面、文档和一次交接培训 |
| 验收标准 | 用哪批真实问题验收？达到什么标准算通过？ | 「效果达到行业领先水平」这类无法测量的措辞 | 双方共建评测集，标准与判定人写进验收单 |
| 后续成本 | 第二年维护费、二期改动人天价、故障响应时限各是多少？ | 签约前含糊带过，说「以后再谈」 | 书面报价，且写进主合同或附件 |
| 业务理解 | 请你复述一遍我们现在这个流程是怎么走的 | 只谈模型和参数，讲不清你的流程 | 能指出你流程里的具体卡点并给出取舍 |
很多招标文件把大量篇幅花在「必须支持哪几个模型」「必须采用某某架构」上，这其实是评估重心放错了地方。模型家族每几个月就有新版本，RAG 与微调的取舍也会随数据积累而变化，这些都是项目中后期可以调整的部分。真正难以挽回的是另外三件事：数据归属没写清、系统交付后没人能改、以及验收标准模糊到扯皮。把评估权重放在这三件上，比锁死技术方案更能保护你的投入。当然，如果你有明确的合规要求（数据不出域、必须国产化），那属于前置约束，应当写死在需求里而不是留给对方选。
降低风险最有效的办法不是把合同写得更厚，而是把第一笔投入变小。选一个边界清晰、有真实使用者、失败了也不影响主业的场景做试点，约定明确的时间窗和验收集。试点期间你能看到的东西比任何尽调都真实：他们提问的质量、遇到问题时是解释还是甩锅、文档写得怎么样、以及交付节奏是否稳定。试点通过再谈整体推广，不通过则损失可控。这也是判断一家服务商是否真有交付能力最省钱的方式 —— 愿意接小试点、并且把验收标准落到纸面的团队，通常比一上来就要求签大单的更可靠。
适用边界
同义问法