不用 Python：纯 PHP + MySQL 搭一套 AI 语义搜索（RAG）

一提”AI 搜索 / RAG”，大多数教程立刻上 Python + 向量数据库（Pinecone、Milvus）。

但如果你就是个 PHP 站（WordPress、Laravel），为了一个搜索功能单独起一套 Python 服务 + 向量库，太重了。几千到几万条数据的规模，纯 PHP + MySQL 就够，还省掉一整套运维。这篇讲怎么搭。

我给自己的 AI 工具站做语义搜索时，就是这么干的——没有 Python、没有独立向量库，全在现有的 PHP + MySQL 里搞定。下面把这套架构和关键决策拆给你。

一、先一句话讲清 RAG 是什么

RAG = 检索增强生成（Retrieval-Augmented Generation）：先从你的知识库里”检索”出最相关的几条，再把它们连同问题一起喂给大模型，让它”生成”答案。核心就两步：检索 + 生成。

为什么需要它？因为大模型不知道你站里的私有数据（你的工具库、你的文章）。RAG 就是给它”现查资料、再回答”的能力——答案基于你的数据，而不是它凭空编。

图1：RAG 的核心就两步——先检索、再生成

二、为什么纯 PHP + MySQL 就够（破”必须上向量库”的迷信）

向量数据库（Pinecone、Milvus）解决的是“百万、千万级向量的毫秒检索”。但你先问自己：你有那么多数据吗？

如果你就几千到几万条，做法极简单：把库里每条向量拿出来，跟问题向量挨个算一遍余弦相似度，排序取前几名。几千条这么算，几十到一两百毫秒就出来了，再加个 Redis 缓存更快。用户根本感觉不到。

这样能省掉：一套 Python 服务、一个向量数据库、以及它们的部署和运维。对一个 PHP 站，这是巨大的简化。判断标准很简单：

数据量 < ~10 万条 + 不追求极致高并发 → 纯 PHP / MySQL 完全够，别过度工程。
数据到几十万、上百万，或要求高 QPS 低延迟 → 那时再上 Milvus / pgvector 也不迟。

三、四块拼图

整套东西拆开就四块，每块都不复杂：

图2：四块拼图——数据入库、问题进来、检索、生成

Embedding（把文本变成向量）。调一个 embedding 接口（我用硅基流动的 BGE-M3，国内稳、跟 DeepSeek 同一个 key），把每条数据的文本变成一串浮点数（向量）。相似的内容，向量也相近。
索引（建库）。遍历你的数据（工具、文章、场景），把每条合成一段描述文本 → 求 embedding → 存进一张 MySQL 表：内容 id、类型、embedding、元数据。
检索（查）。用户问题也求 embedding → 跟库里每条算余弦相似度 → 取最相似的 top-k。
生成（答）。把 top-k 的原文 + 用户问题，拼成一段 prompt，喂给 DeepSeek 这类 chat 模型，生成最终答案。

四、关键决策 & 坑

embedding 存 LONGBLOB，别存 JSON 文本。把浮点数组 pack() 成二进制存进 LONGBLOB，读的时候 unpack()。比存 JSON 字符串省一大半空间、读取也快。
余弦相似度就在 PHP 里算。一个循环：点积 ÷（两个向量的模长相乘）。几千条无压力。把查询结果丢进 Redis 缓存，重复查询直接命中。
换 embedding 模型 = 必须重建索引。不同模型产出的向量不通用，混着用检索就是乱的。表里存一个 embedding_model 字段，换模型时按它筛出旧的重建，不用删表。
加一层关键词做”混合检索”。纯向量偶尔会漏掉”精确匹配”的场景（比如用户搜一个具体工具名）。向量召回 + 关键词召回一起上，结果更稳。
LLM 调用要限流。embedding 和 chat 都按量计费。按用户 / 套餐限次（我这免费 5 次/天、Pro 100 次/天），别让人（或爬虫）刷爆你的账单。
开发期别写循环狂打第三方 API。embedding / LLM 都花钱，调试用少量样本，别一个 for 把额度烧光——这个坑我提醒过自己好几次。