向量数据库火成这样，你是不是也悄悄把嵌入向量丢进独立向量库，业务数据留在传统库里？早期原型确实跑得快——但真正上线那天，审计、权限、过滤逻辑，全在网关处断了线。

Oracle 干脆把向量塞进了数据库内部。在已有的内容、元数据、来源信息表里，直接加一个 VECTOR 类型的列，嵌入向量就住在这里。然后建个近似最近邻索引——HNSW 或 IVF——检索全在 SQL 里完成。数据库原有那一套行级安全、审计、数据脱敏策略，自然而然也管到向量查询。不另起炉灶，治理就不用重做一遍。

打开网易新闻 查看精彩图片

混合检索更直接：用 VECTOR_DISTANCE 函数做语义相似度，WHERE 子句加业务过滤条件，一条语句全都写上。谁都能读懂这条 SQL：什么行被选出来、为什么选出来，审阅会上解释成本几乎为零。

但索引别随便挑。HNSW 和 IVF 在召回率、内存占用、查询延迟上各有真刀真枪的取舍。没有哪个是默认最优解，你得拿自己的语料测过再决定——别拿着别人的基准硬套。

答案生成那一步也别变成黑盒。连接检索和 Select AI 画像，配上 SHOWSQL，模型生成的 SQL 在执行前就能被审阅，不是只靠检索结果猜它干了什么。

前提也明确：你需要 Oracle AI Database 26ai 或已启用 AI Vector Search 的自治数据库，建表和建索引的权限，以及按组织策略配好网络和凭据。动手前，确认一下 CREATE VECTOR INDEX 的选项和 DBMS_* 包的签名——免得自动化脚本跑一半卡住。