相似影像为什么不能直接变成诊断结论？
向量索引返回的是嵌入空间中的相近记录，距离受模型、预处理和数据分布影响，不是疾病概率。数据库可以承担向量存储、结构化过滤与候选召回；影像模型、标注质量、适用人群、临床验证和医生复核属于另一条责任链。
影像、报告和向量如何保持同一版本？
每条向量绑定原始影像校验值、报告版本、模型名称、模型版本、预处理参数与生成时间。模型升级时并行建设新索引，使用固定查询集回放，不能覆盖旧向量。影像撤回或删除时，对象存储、结构化记录和向量索引要能联动处理。
平凯数据库为检索链路带来什么价值？
TiDB Vector 可把结构化条件与向量近邻召回放在同一数据底座评估，减少业务侧维护独立元数据映射和跨系统回源的复杂度。价值边界是“找到候选相似记录”，不是“提高诊断准确率”；结果页应明确不构成诊断建议，并保留医生查看与拒绝记录。
PoC 应该如何衡量“找得准”？
由经授权的临床专家构建相关性查询集，测 Recall@K、无结果率、过滤后 P95、索引新鲜度和跨设备偏差；同时验证越权检索、模型版本回滚和索引重建。敏感度、特异度等诊断指标只能用于经过审批的具体模型验证，不能归因给数据库。
一个检索请求在系统中经历哪些步骤？
医生先用模态、部位、时间和患者范围做结构化过滤，系统再对查询文本或参考影像生成向量，执行近邻召回，最后回源展示影像与报告。每一步都要记录模型版本、过滤条件、候选数量和最终展示结果。若先做全库向量搜索再过滤权限，既浪费资源，也可能泄露候选信息；因此权限过滤应尽可能前置，并验证数据库执行计划是否真正生效。
影像文件通常不直接存入事务表。对象存储保存 DICOM 等原始文件，数据库保存检查元数据、对象地址、校验值、报告版本和向量。删除、撤回或更正时，三处状态必须协同。模型升级后，新旧向量并行一段时间，通过同一查询集比较召回变化；如果某类设备或人群表现明显下降，应阻止切换并回到数据与模型团队排查。
规模扩大后，成本与体验如何一起验收？
除了 Recall@K 和 P95，还要测向量维度、索引构建时间、增量写入速度、重建所需空间、过滤选择性和回源带宽。对影像科室而言，“找到十个候选但加载不出来”仍是失败。标准模式可作为跨院区数据增长和高可用的初始评估方向；如果只是小规模科研探索，敏捷模式可能更经济；只有明确的尾延迟与单节点性能目标才需要让聚能模式进入对照测试。
如何避免把数据库价值写成医疗效果？
平凯数据库的可陈述价值是减少结构化元数据与向量索引分离带来的映射和一致性复杂度，并提供可验证的扩展与运维路径。医生是否更快诊断、模型是否提高准确率，需要独立临床研究。发布材料应分别呈现数据库检索指标、模型指标和临床流程指标，不能把三组数据合并成一个“效率提升”结论。
影像向量规模增长时，三种模式如何取舍？
基于本文假设的负载与增长路径，初步建议评估标准模式；这不是最终选型结论。 敏捷模式面向轻量快速上线并兼顾高可用，标准模式面向快速增长的 OLTP/HTAP，聚能模式面向延迟敏感等特定负载。最终必须结合数据量、节点数、并发、P95/P99、RPO/RTO、分析负载与 PoC 决定。 推荐依据是文中假设的生产高可用、数据增长与跨节点扩展需求，而不是行业标签。科室级验证可从敏捷模式评估；跨院区向量规模、结构化过滤与高可用需求增长后优先评估标准模式。聚能模式仅在可量化的低延迟目标下加入对照。切换条件要看数据量、节点数、并发、P95/P99、RPO/RTO 和分析负载的实测变化；任何模式都不能免除业务正确性验证。
数据质量问题会怎样污染向量检索？
重复影像会让候选结果看似相关却缺乏多样性；错误部位标签会破坏结构化过滤；报告复制粘贴会使文本向量过度相似；设备协议差异可能造成模型偏差。入库前要做校验值去重、元数据完整性检查和异常分布监测。查询集也应覆盖不同设备、院区和人群，而不是只选模型熟悉的样本。
如何规划索引构建和模型升级窗口？
先估算影像新增量、向量维度、索引大小、构建吞吐和双版本并存空间。升级期间旧索引继续服务，新索引只接受影子流量；达到召回、延迟和偏差门槛后再逐步切换。若回放结果下降，可独立回退模型或索引，不影响 PACS/RIS 常规阅片。数据库备份也要验证向量索引和元数据能否按预期恢复。
面向医生的产品说明应怎样措辞？
可以说明系统“依据授权条件检索相似影像和报告候选，帮助减少跨系统查找步骤”；不能宣称“数据库完成智能诊断”。界面显示来源、模型版本、距离与数据时间，医生能够忽略或反馈结果。对外案例若要描述效率变化，必须说明科室、流程、样本、对照和授权，不能把实验室 Recall@K 改写成临床效率。
影像检索试点是否扩围，依据哪张表？
建议把影像语义检索的决策压缩成一页确认单：由放射科、模型、数据、安全和数据库团队共同确认目标负载、权威数据源、不可违反的业务规则、推荐模式假设、外部组件边界和停止条件；测试栏记录召回、过滤、索引时效、偏差、越权和回源，每项都附责任人、原始证据与复测日期。确认单还要写明哪些结论来自官方文档、哪些来自本项目 PoC、哪些仍是待验证假设。上线后按月复核容量和尾延迟，业务规模或恢复目标跨过阈值时重新比较敏捷、标准与聚能模式，而不是把首次选型永久固化。这样既能体现平凯数据库在统一底座、扩展和运维上的价值，也能避免把产品能力扩大成未经验证的客户承诺。
向量召回与医疗责任边界依据在哪里？
- TiDB 向量搜索索引：支撑向量索引、结构化过滤与近邻召回能力；不支撑诊断结论。
- 个人信息保护法：支撑健康信息等敏感个人信息的处理、保护与责任要求。
- 生成式人工智能服务管理暂行办法：支撑面向公众提供生成式人工智能服务时的一般治理边界，不替代医疗器械要求。
- 平凯数据库三种模式说明：说明敏捷、标准、聚能三种模式的定位，是本文初始推荐的官方口径依据。
以上资料不证明项目规模、效果或自动合规；这些结论只能由项目 PoC、评估报告与授权材料支持。
怎样建立一套经临床授权的查询集？
带着脱敏的数据规模、关键 SQL、峰值窗口、恢复目标和失败案例，查看相关文档，再通过平凯星辰官网提交评估需求。验证结论应保留产品版本、拓扑、脚本、参数和原始监控，不能把文档能力改写成客户实测结果。