最近帮客户落地知识库问答时最折磨人的环节不是大模型也不是主流程而是“文档处理”。你辛辛苦苦搭好了RAG链路结果一段PDF转出来的文本全是乱码或者分块时把一段业务含义切得稀碎再强的检索模型也救不回来。正好最近手头项目里深度用到了Oracle AI Vector Search这个从Oracle 23ai版本开始内置的数据库级向量检索能力把文档处理到向量入库的整条链路都收进了数据库里。这篇从“数据连接器”的角度把Oracle AI Vector Search做文档处理时那些关键步骤、坑和取舍一次说清楚适合正在搭RAG知识库、还在纠结要不要单独部署向量数据库的团队参考。这篇我定义成data_connectors系列的第25篇重点不放在模型调优上而是聚焦在“文档怎么从一堆PDF、Word、HTML变成能直接被检索的向量块”这件事上。毕竟RAG的上限由模型决定下限却是文档处理决定的上下文质量不行回答就不可能准。1. Oracle AI Vector Search能帮你解决什么问题1.1 它到底是个什么东西先澄清一个容易混淆的点。Oracle AI Vector Search不是某个独立服务而是Oracle 23ai数据库内置的一套向量存储与相似度检索能力。你可以在普通表里定义一个VECTOR类型的列往里面写向量数据用SQL做距离计算支持余弦相似度、欧氏距离、曼哈顿距离这些常见度量还可以建HNSW或IVF向量索引来加速检索。对于做RAG的人来说它最直接的意义在于你不需要再单独部署一个向量数据库了。业务数据本来就存在Oracle里那么向量也一起放进去省掉了一条业务库到向量库的双写同步链路。数据不需要搬来搬去事务一致性由数据库本身保证备份恢复也沿用了原有的体系运维心智负担一下就降下来了。如果你的团队预算有限、不想额外管理一套ES或者FAISS集群这个方案尤其值得试。Oracle 23ai这个版本命名很多人还不太熟它其实就是原来的23c后来被市场部改叫23ai核心就是想强调AI能力内置。如果你手头是19c以下的版本没有VECTOR类型那这篇文章的大部分内容没法直接跑通需要先升级或者用云上的23ai实例。1.2 在RAG流程中到底处于什么位置一条标准的RAG管路从原始文档到大模型能用的上下文通常要经历源数据接入、文本抽取、清洗、分块、向量化、向量入库、相似度检索、重排、拼Prompt。大家聊RAG的时候总是把注意力放在embedding模型选择、检索器参数这些环节但实际项目里最容易翻车的恰恰是前面的文档处理。我说的“文档处理”不是一个单纯的技术步骤它决定了后续检索的输入质量。如果PDF文本抽取出来是乱码分块时把表格和标题切得七零八落那不管你的向量索引建得多漂亮检索到的都是垃圾片段。大模型再聪明也只能基于你喂进去的内容回答。所以很多团队做RAG项目做到后面会发现真正花时间的不是接大模型而是把文档处理管线打磨稳定。Oracle AI Vector Search在这个流程里扮演的角色是“数据处理存储检索”二合一。它有工具包专门做文本提取和分块也可以直接在SQL里完成向量入库和相似度检索外部RAG框架只需要把需要检索的query向量传进来就能拿回Top K相关文本块。对架构师来说这相当于把RAG链路里最脏最累的活尽量压到靠近数据源头的地方解决。1.3 什么场景下才值得选它选择不等于无脑推荐。我见过不少团队已经有一套成熟的向量数据库体系那我不建议他们为了用Oracle AI Vector Search去做迁移。这个方案真正适合的场景一是企业核心业务数据本来就在Oracle里不希望为了一个AI功能把数据复制到外部系统二是对数据安全要求高不希望文档内容出库去做embedding希望嵌入计算尽可能发生在数据库内部三是团队里Oracle DBA经验丰富但缺少独立的向量数据库运维能力。对比一下常见的方案用pgvector的话如果你的主业务库不是PostgreSQL等于还是要维护一套新库用FAISS这类开源库又得自己搞定持久化、元数据过滤和分布式问题用MongoDB Atlas Vector Search其实也是引入一个新存储系统。而Oracle AI Vector Search把VECTOR类型、索引、检索SQL全部并进了现有数据库体系对已经在Oracle上运行了多年的系统来说学习成本和架构改动都小很多。当然它也有短板比如社区生态没有开源向量库那么热闹部分高级特性需要企业版授权这些在选型时都要算进成本里。2. 文档处理链路拆解与实操要点2.1 文本抽取用DBMS_VECTOR_CHAIN.UTL_TO_TEXT文档处理的第一步是把PDF、Word、HTML这种非结构化文件变成纯文本。Oracle提供一个内置的实用工具包DBMS_VECTOR_CHAIN里面的UTL_TO_TEXT函数就是干这个的。它不需要你额外安装PDF解析器或者第三方库只要数据库服务器能读取到文件路径就能在PL/SQL里直接调用返回CLOB文本。不过在实操前有一个必须搞明白的前提数据库进程跑在服务器上它能访问的是数据库所在服务器的文件系统不是你本地电脑上的路径。你需要先创建DIRECTORY对象把服务器上的某个目录映射成Oracle数据库里的逻辑目录然后还要把对该目录的READ权限授予执行处理的用户。这一步卡住过不少人报错往往就是ORA-00942或者权限不足之类的其实只是忘了授权DIRECTORY访问。UTL_TO_TEXT支持的文件类型包括PDF、DOCX、HTML、JSON、CSV、TXT等常见格式。这里有个很重要的限制它处理的是“文本型PDF”也就是那种可以直接选中文字的PDF。市面上很多扫描件PDF本质上是一张图片必须先经过OCR识别UTL_TO_TEXT不会自动帮你做OCR。如果你的文档库里扫描件比例很高就要在管线上游另接OCR服务先把图片转成文字再让UTL_TO_TEXT接手。这一点如果不在方案设计阶段想清楚后面数据处理时会发现一大批文档检索结果质量奇差怎么调都没用。文本抽出来后也别急着直接用需要做清洗。我看到很多新手直接拿原始抽取结果去分块结果里面全是页眉页脚、页码、重复的空行、表格错位符这些噪音都会污染向量语义。我的习惯是抽完文本后先做一轮轻量清洗比如去掉连续空行、规范换行符、把UTF-8编码乱码的字符标记出来人工复核。清洗这一步可以在SQL里用正则表达式处理CLOB也可以把文本拉出来到Python里做取决于你们管线的技术栈习惯。2.2 分块阶段别拿“固定长度”对付一切文档文档处理里最容易做出“看起来没问题、实际检索效果稀烂”的环节就是分块。Oracle AI Vector Search提供了两种方式低层是SQL函数VECTOR_CHUNKS高层是DBMS_VECTOR_CHAIN.UTL_TO_CHUNKS。用起来都不复杂关键是分块策略本身要想清楚。先看基础参数。分块必然要面对“块大小”和“重叠大小”。Oracle支持按字符数by chars、按单词数by words和按词汇表by vocabulary三种方式切块同时可以设置chunk_size和chunk_overlap。对于英文等按空格分词的语言按单词切块很自然但对于中文按字符合理得多因为中文不像英文有天然空格边界Oracle内置逻辑并不替你承担中文分词职责。我习惯设成每块500到800个字符重叠150到200个字符具体数值取决于业务文本密度。为什么要重叠因为文档在切块边界处可能会切断语义比如一个长句被拦腰截断或者一个表格的列头和数据行被分到不同的块里导致检索时只召回了后半段上下文语义不完整。加了重叠后相邻块之间共享一段文本检索命中边界的概率会提高。重叠也不是越大越好过大的重叠会导致一个内容点重复出现在多个块里检索结果大量重复反而稀释了有效上下文。更讲究一点的做法是按语义边界分块。Oracle的VECTOR_CHUNKS允许你传一个JSON配置里面可以指定分块时要不要按段落、标题、或者文档结构来切。实际操作中我强烈建议你在分块前先把文档结构摸一遍。比如一份Word文档导出的HTML里H1、H2标题就代表了逻辑边界一份产品手册里每个章节是一个完整业务主题。如果无视这些结构硬按字符数切即使块与块之间文字通顺检索到的内容也可能是“半个章节”回答自然显得没有上下文。还有一种常见需求是把表格存进RAG知识库。系列产品配置表、订单明细表这类半结构化文档最忌讳按纯文本方式切块切完表头和数据就分家了。我见过比较实用的做法是把表格转成Markdown格式或者JSON格式保留行列表结构后再进分块管线。这样检索出来的是一个结构化片段大模型阅读起来远比一段被拍扁的纯文本要容易理解。Oracle本身支持对JSON这种半结构化数据进行处理所以用UTL_TO_TEXT提取后如果原格式是表格优先考虑保持结构而不是压成纯文本。2.3 嵌入模型本地ONNX与外部API之间怎么选文档从文本变成向量这一步是RAG的核心。Oracle AI Vector Search支持两种嵌入生成路径一种是在Oracle内部直接运行ONNX格式的嵌入模型数据不出库另一种是应用端调用外部Embedding API拿到向量后再写进数据库。两种方式没有绝对好坏关键在于你的数据合规要求和算力条件。先说ONNX本地推理。你需要先准备一个嵌入模型转换成ONNX格式然后通过Oracle提供的工具加载进数据库。模型加载完成后调DBMS_VECTOR.UTL_TO_EMBEDDING就能在SQL里直接把文本转成向量全程不离开数据库。这种方式的优势非常明显文档内容不会因为要生成向量而被发送到外部接口保密性拉满同时也没有网络延迟和外部接口限流的问题。缺点是数据库服务器要有CPU或GPU资源跑推理而且ONNX模型的选择和转换需要一些模型工程经验模型小效果就弱模型大又占内存需要做权衡。再说外部Embedding API。这种方式灵活团队可以自由选择目前效果最好的商用或开源embedding模型比如各类中文向量模型、多模态向量模型等。应用端把分好块的文本批量发给接口拿回一组组向量再通过INSERT语句绑定参数写进Oracle的VECTOR列。这样Oracle只负责存储和检索不承担推理实现起来很直接也方便你随时切换embedding模型。但要注意文本出库意味着内容可能落在外部服务那里对数据安全要求高的项目必须谨慎同时调用外部接口要注意限流批量入库时最好做并发控制和失败重试。从项目落地的角度看我的建议是如果数据规模不大内部推理也没有明显性能瓶颈优先用ONNX本地推理省掉一条外部依赖如果团队本来就在用某个成熟的embedding服务比如已经跑通了别家的向量模型那就走外部API没必要为了“全数据库化”而强行换模型。重要的是向量维度要保持一致这直接关系到后面表和索引的定义。2.4 向量表与索引决定查询性能的关键设计向量入库前先要把表结构设计好。Oracle里一张向量表很直接比如CREATE TABLE doc_chunks ( id NUMBER GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY, doc_id NUMBER NOT NULL, doc_name VARCHAR2(500), chunk_seq NUMBER, chunk_text CLOB, chunk_vec VECTOR(1024, FLOAT32) );VECTOR类型后面的1024表示向量维度必须和你选用的embedding模型输出维度一致。比如很多开源中文模型输出768维OPENAI的text-embedding-3-small输出1536维写错了插入就会报错。担心维度写死以后不好改的话也可以声明成VECTOR(*, FLOAT32)让Oracle根据首次插入的数据自动推断维度但对索引定义和查询性能优化来说还是显式声明维度更可控。建完表之后要让检索跑得快必须建向量索引。Oracle支持两种主要索引类型HNSW和IVF。HNSW是分层可导航小世界图索引适合对召回准确率和查询延迟都敏感的场景建好后不需要额外训练过程IVF是倒排文件索引需要先做聚类训练适合数据量特别大、可以接受一定程度准确率损失的场景。对于一般团队的知识库体量我建议直接用HNSW参数省心效果稳定。建索引的SQL有点长我直接给一个常见写法CREATE VECTOR INDEX doc_chunks_hnsw_idx ON doc_chunks(chunk_vec) ORGANIZATION NEIGHBOR PARTITIONS DISTANCE COSINE WITHIN DISTANCE 0.5 WITH OPTIONS (GRANULARITY100, TYPEHNSW, NEIGHBORS40, EF_CONSTRUCTION200) ;这里DISTANCE COSINE表示用余弦距离文本检索基本都用它NEIGHBORS和EF_CONSTRUCTION是HNSW图构建时的参数直接影响索引质量和构建内存占用。索引创建可能需要一点内存如果你在比较小的环境里测试还需要提前调整VECTOR_MEMORY_SIZE这类实例参数不然会看到资源不足类的报错。检索时用VECTOR_DISTANCE函数算相似度典型写法是按距离排序取前N条SELECT doc_name, chunk_text, chunk_seq FROM doc_chunks ORDER BY VECTOR_DISTANCE(chunk_vec, :query_vec, COSINE) FETCH FIRST 10 ROWS ONLY;到这里一个RAG知识库的存储和检索底座就成型了。下一步要解决的就是如何把真实业务数据喂进来以及如何接入上层RAG框架。3. 端到端实操从文档到RAG检索3.1 准备环境与权限先准备一个Oracle 23ai实例。如果你只是测试可以用Oracle官方提供的免费版镜像或云上免费实例跑在Docker里也行。要注意的是AI Vector Search相关功能需要有授权免费版里一般是可以体验的生产环境记得和销售确认清楚许可边界。实例起来后先建一个专门用户比如RAG_USER然后按最小权限原则授权。最关键的三类权限分别是对DBMS_VECTOR_CHAIN的执行权限、对向量索引的CREATE权限、对DIRECTORY的读写权限。下面语句可以在DBA用户下执行CREATE USER rag_user IDENTIFIED BY YourPassword DEFAULT TABLESPACE users QUOTA UNLIMITED ON users; GRANT CONNECT, RESOURCE TO rag_user; GRANT EXECUTE ON DBMS_VECTOR_CHAIN TO rag_user; GRANT CREATE VECTOR INDEX TO rag_user;目录授权也是高频忽略点。假设你的文档放在服务器/opt/oracle/docs下就要创建目录并把读写权授出去CREATE OR REPLACE DIRECTORY DOCS_DIR AS /opt/oracle/docs; GRANT READ, WRITE ON DIRECTORY DOCS_DIR TO rag_user;这一步做完之后数据库才能读到物理文件。我遇到过很多次文档明明放在服务器上了但SQL里就是报“file not found”最后排查出来都是目录映射或权限的问题。3.2 文档入库的完整流程权限就绪后就可以跑一个标准的入库流程了。我先说外部Embedding API这种方式因为它更通用也更容易和现有RAG框架对接。以Python配合python-oracledb驱动为例流程分四步读取文档文本、按策略分块、调用外部embedding API生成向量、批量写入doc_chunks表。伪代码大致是这样import oracledb conn oracledb.connect(userrag_user, password..., dsn...) cursor conn.cursor() doc_name 产品手册.pdf # 1. 通过UTL_TO_TEXT取文本也可以应用端自己解析PDF text cursor.callfunc( DBMS_VECTOR_CHAIN.UTL_TO_TEXT, oracledb.CLOB, [DOCS_DIR:产品手册.pdf] ).read() # 2. 在Python端分块我这里假定你已经实现好函数 chunks chunk_document(text, chunk_size600, overlap150) # 3. 对每个块调用embedding接口得到向量 vectors [embedding_api(c) for c in chunks] # 4. 批量入库 for i, (chunk, vec) in enumerate(zip(chunks, vectors)): cursor.execute( INSERT INTO doc_chunks (doc_id, doc_name, chunk_seq, chunk_text, chunk_vec) VALUES (1, :name, :seq, :txt, :vec), {name: doc_name, seq: i, txt: chunk, vec: vec} ) conn.commit() cursor.close() conn.close()这里有个小细节VECTOR列在绑定参数时可以直接传Python列表或numpy数组python-oracledb能自动处理。如果你的环境里分块也在数据库内完成那更简单直接用VECTOR_CHUNKS函数生成块再配套UTL_TO_EMBEDDING一起写成一条INSERT...SELECT全部在SQL内闭环。那种方式对数据保密要求极高、不希望文本经过应用服务器的场景特别合适。批量入库的时候要注意一次塞大量数据可能会触发UNDO空间膨胀或者超出事务日志的处理能力稳妥的做法是分段提交比如每500条commit一次同时加上重试逻辑避免外部embedding接口抖动导致整个任务失败重来。向量计算本身也耗费CPU可以的话尽量在业务低峰期跑批不然会把数据库CPU打满影响在线业务。3.3 在LangChain / Spring AI等框架里做检索文档入库之后接下来就是怎么把这套东西接进RAG应用。很多人一听“Oracle AI Vector Search”就以为必须用Oracle的专用客户端其实它对外就是一个标准的关系型数据库LangChain、LlamaIndex、Spring AI这些框架都认Oracle的连接方式。以LangChain为例如果你只是想拿Oracle当向量存储来用生态里已经有对应的集成组件。但更朴素的接入方式是应用里直接执行SQL完成检索再接大模型。它不依赖特定框架换语言也通用query_vec embedding_api(客户问某某产品的保修期多长) cursor.execute( SELECT doc_name, chunk_seq, chunk_text FROM doc_chunks ORDER BY VECTOR_DISTANCE(chunk_vec, :query_vec, COSINE) FETCH FIRST 5 ROWS ONLY , {query_vec: query_vec}) contexts [row[2] for row in cursor.fetchall()] prompt 基于以下资料回答用户问题:\n \n---\n.join(contexts) # 接着调用LLM生成回答这样做的好处是绕过框架内部封装你完全知道每一步发生了什么出了问题也好排查。对于Java技术栈Spring AI和LangChain4j同样可以连Oracel本质上都是走JDBC/Thin驱动执行向量查询再把结果喂给LLM。如果团队正在对比“langchain4j rag”和“spring ai rag”选型我建议先用一个最小Java示例把Oracle的向量查询跑通再接入框架这样后续框架升级也不至于影响底层检索逻辑。检索这块有两个工程细节要提一下。一是元数据过滤实际业务里很多查询需要限定文档类型、部门、日期范围不要让向量检索在全库范围扫。doc_chunks表设计时就该预留足够的业务字段检索SQL里同时写上等值过滤条件向量索引照样能用。二是Top K取值不是越大越好我一般先取5到10条观察回答质量和上下文占用。如果给定上下文太长大模型推理成本会明显上升回答也容易“淹没”在无关内容里。3.4 多轮对话、Agent等场景里的检索设计基础RAG跑通之后你会开始思考更复杂的问题用户追问、上下文衔接、工具调用和检索怎么协同。这些是RAG落地中必然遇到的进阶需求。多轮对话场景最典型的问题是用户第二句问“那价格呢”如果直接用这句话去向量检索返回结果大概率不理想因为缺少指代主体“产品”。这里推荐的做法是在检索前加一个query改写环节把最近几轮的对话摘要成一句完整的独立问题再用改写后的query去做向量检索。改造后的检索语句可以放进上一条SQL里整个链路不用动数据库。如果你的团队正在做rag多轮对话设计这个“先改写再检索”的思路是性价比最高的一步。Agent场景就更进一层。所谓agentic rag不是简单把LLM和检索串起来而是把向量检索当做一个工具由Agent在推理时决定要不要调用。比如用户问“查一下去年库存高于阈值的产品清单”Agent可以先通过结构化SQL查询拿到结果如果结果中有说明性文本需要解释再触发向量检索去读对应文档。这种模式下Oracle里的向量检索只是Agent工具箱里的一个函数调用方式仍然是执行SQL但控制权交给了Agent的推理逻辑。还有一些团队在尝试Ontology RAG也就是在检索前先用一个业务本体层把概念关系梳理清楚让检索限定在相关的语义子图内。这个方向对文档处理的要求比普通RAG更高因为分块时就要把实体关系和文档片段关联起来。如果你正在做知识库项目可以先从基础的chunk-text入库开始等业务方反馈出“检索到相关内容但不精确”时再逐步引入关系过滤和重排不必一口气上最复杂架构。4. 常见问题与排查技巧实录4.1 扫描件PDF读不出来、文本全是乱码这个问题排在所有坑的第一位。UTL_TO_TEXT从文本型PDF里抽取文字很顺滑但遇到扫描件也就是图片型PDF抽出来的要么是空字符串要么是无数乱码符号。这类PDF必须先做OCR。很多团队把扫描件丢进管线后没检查等到检索阶段发现怎么都查不到内容回头才看到文本表里全是垃圾。排查技巧也不复杂抽取完文本后统计一下长度文本型PDF抽出来的字符数应该和原文档页数有合理的比例关系比如每页几百到几千字符扫描件如果没做OCR抽出来几乎是0。你可以在入库任务里加一个文本长度阈值告警低于阈值的文档自动标记为待人工处理。对扫描件比例高的项目我建议在文档处理前置环节默认接一套OCR识别服务识别成文字后再走UTL_TO_TEXT或直接文本入库这样管线才稳定。4.2 文档表格被分块切碎、检索命中残缺数据这类问题隐蔽且影响大。一份产品规格表表头是“型号、功率、尺寸”下面的行是具体数值如果按普通文本硬切很可能某个chunk里只有数据没有表头检索出来大模型也读不懂。我处理这类问题有两个实操手段。一是转格式思路文档在抽取阶段就保留结构化形态比如把表格转成Markdown或JSON再入库而不是压成纯文本。二是分块参数调整对包含表格的文档把chunk_size调大一些同时设置chunk_overlap覆盖到表格前后相邻段落保证表头和数据行尽量落在同一个块里。如果表格特别大干脆单独建一张“表格知识库”表每一行存一个完整表格的Markdown表示检索时按表名称检索效果比硬切文本好得多。4.3 向量索引建好但查询没有走索引、检索越来越慢建了HNSW索引但查询却执行了全表扫描这类问题我在优化阶段遇到过好几次。通常原因有几个查询SQL里对向量列做了函数转换导致索引失效或者查询时同时加了业务过滤条件优化器估算下来觉得全表扫描更快再或者向量索引构建时的参数没调对比如NEIGHBORS设置太小导致召回质量下降检索结果噪声变大。定位方法很简单先看执行计划。如果发现Oracle选了全表扫描可以通过加hint强制走向量索引或者检查过滤条件列上有没有普通索引。别忘了向量距离计算也是有成本的如果业务过滤条件能把候选集压到几千行以内有时全表扫描并不慢。索引参数调整方面NEIGHBORS值我一般设在40到64之间EF_CONSTRUCTION在200左右内存充足时可以再往上加但也要关注VECTOR_MEMORY_SIZE是否够用。4.4 权限与网络ACL相关的坑数据库里跑文档处理和向量检索权限问题比普通业务表要多一圈。除了前面提到的DBMS_VECTOR_CHAIN执行权限、CREATE VECTOR INDEX权限、DIRECTORY读写权限还需要注意如果embedding走的是外部API而且你是从Oracle内部发起HTTP请求做推理那就要配网络ACL访问控制列表把外部服务地址显式加进允许列表里。这里报ORA-24247时就意味着网络权限没放开。如果你是应用端调用外部embedding API再把向量INSERT进Oracle应用服务器和数据库之间的网络也要通生产环境里通常要确保数据库用户连接白名单允许应用服务器IP。另外如果你在23ai免费版上测试有些权限模型和企业版略有差异不要拿生产环境经验直接套。先小规模试通再上生产能省掉大量排查时间。这里还有一个容易被忽略的细节UTL_TO_TEXT在处理大文件时会吃掉不少内存如果文档超过几十MB建议在批处理脚本里加上单文件大小限制超限的单独队列人工处理。别让一个巨型PDF把整个入库任务拖垮这是经验之谈。
