searchGPT：用 RAG 重新定义搜索引擎，让 AI 回答有据可查

一、痛点场景：当 AI 遇上"幻觉"

想象一下这样的场景：你在凌晨三点查资料，问 ChatGPT "什么是暗能量"，它洋洋洒洒写了一段，结果你拿去和教科书对照，发现有一半是胡编的。这种"一本正经胡说八道"的现象，在 AI 领域叫做 LLM 幻觉（Hallucination）——大模型的训练数据有截止日期，且无法覆盖所有专业领域，问它冷门问题就像让一个记忆有限的人即兴演讲，越说越离谱。

searchGPT 正是为解决这个痛点而生。它将 LLM 与实时网络搜索结合，构建一个有据可查的问答引擎（Grounded Search Engine）：用户提问 → 搜索引擎抓取相关网页 → LLM 阅读并提炼 → 给出带引用来源的答案。从本质上讲，这是 RAG（检索增强生成）架构在搜索引擎领域的一次工程落地。

二、项目背景与作者故事

searchGPT 由独立开发者 michaelthwan 创建，托管于 GitHub（712★，MIT 许可证），采用 Python 开发。这是一个从 2022 年就开始维护的早期 LLM 应用项目，其核心灵感来自"新版必应搜索"（New Bing）——让 AI 不仅能回答，还能告诉你"我是怎么知道的"。

项目的技术选型体现了早期 LLM 应用开发的典型路径：Python + OpenAI API + Bing 搜索 + Flask 前端，架构清晰，代码量适中，非常适合作为 LLM 应用开发的入门参考。

三、核心功能拆解

3.1 两阶段 RAG 问答流程

searchGPT 的工作流程分两个关键阶段：

第一阶段：检索（Retrieval）

• 调用 微软必应搜索 API 实时抓取网页
• 通过 trafilatura 或 BeautifulSoup 提取网页正文
• 可选：本地文件索引（支持 PPT/DOC/DOCX/PPTX）
• 每条信源限制最多 20 句文本，平衡信息量与处理成本

第二阶段：生成（Generation）

• 将检索到的内容作为上下文（Context）注入 LLM prompt
• 支持 OpenAI GPT-3.5-turbo（性价比最优）和 GPT-4（精度更高）
• 同时支持 GooseAI 作为平替 API 提供商
• 输出时附带来源编号（如 [1]、[2]），实现答案可溯源

3.2 源码架构解析

项目代码位于 src/ 目录，按职责清晰分层：

模块	职责
BingService.py	封装必应搜索 API 调用
SearchGPTService.py	核心问答逻辑，编排检索→组装→生成流程
LLMService.py	OpenAI/GooseAI 接口抽象，支持多模型切换
SourceService.py	信源管理，编号与内容映射
SemanticSearchService.py	语义搜索（FAISS/PyTerrier，目前注释状态）
NLPUtil.py	NLP 工具函数
flask_app.py / gradio_app.py	双前端：Flask 自主托管 或 Gradio 快速原型
website/	Flask 前端模板（templates/ + static/）

3.3 Grounded vs Ungrounded 对比

作者在 README 中放了一组直观的对比实验：

问题	无 Grounding 的 LLM 回答	searchGPT 的 Grounded 回答
"什么是 ghost kitchen"	编造"幽灵厨师"等玄幻故事	"ghost kitchen 是外卖专用厨房，无堂食" + 3 个来源
"日文中 wwww 是什么意思"	胡乱解释	"表示好笑、调侃，也可表示同意" + 2 个来源

这个对比清晰展示了 Grounding 的核心价值：不是 LLM 有多聪明，而是有没有给它正确的参考资料。

四、技术栈全景

searchGPT 的技术栈代表了 2022-2023 年间 LLM 应用开发的主流方案：

后端框架：Flask 3.1 + Gunicorn 生产级部署
LLM 层：OpenAI API（gpt-3.5-turbo / gpt-4）
搜索层：微软必应搜索 API v7
文档解析：python-docx、python-pptx、trafilatura（网页正文提取）
Embedding：tiktoken（OpenAI 分词器）+ scikit-learn（语义工具）
前端：Flask Jinja2 模板 + 可选 Gradio 快速 UI
数据：pandas + numpy + matplotlib/plotly（数据可视化）

五、上手体验

部署前置条件

部署 searchGPT 需要准备三个 API Key：

1. OpenAI API Key（或 GooseAI Key）：新账号有免费额度（OpenAI 首 $18，GooseAI 首 $10）
2. Azure Bing Search API Key：有免费套餐（3 次/秒，1000 次/月）
3. Python 3.10.8：项目明确要求此版本

两种运行模式

• Web UI 模式（推荐）：python app.py，通过 Flask 前端交互，API Key 可在页面上填写
• CLI 模式：python src/main.py，直接输出问答结果，适合调试

⚠️ 重要注意事项

1. 项目已归档：作者已在 README 标注 This project is archived，不再维护，功能不会更新
2. API 成本：每次搜索消耗 OpenAI token + Bing API 调用，频繁使用需关注账单
3. 模型选择：gpt-3.5-turbo 是性价比之选（$0.002/1K tokens），gpt-4 精度更高但成本是前者约 50 倍
4. 搜索质量依赖：答案质量直接受 Bing 搜索结果影响，冷门话题可能返回无关内容

六、局限与风险

维度	现状	风险
项目状态	已归档，不再更新	功能停滞，不修复 Bug
API 成本	每次查询消耗 OpenAI + Bing 费用	大量使用可能产生账单
搜索质量	依赖 Bing API 返回结果	冷门问题可能无相关网页
多语言支持	通过 config.yaml 切换语言	非英语搜索质量可能下降
扩展性	代码量小，模块化好	但缺少异步处理，大规模并发有瓶颈

七、行业意义

searchGPT 虽然已归档，但它代表了 LLM 应用开发的一个重要方向——RAG 架构的工程化落地。它的核心理念（让 LLM 回答有据可查）在 2024-2025 年被广泛继承和发展：

• Perplexity.ai 将这一理念产品化，成为 AI 搜索引擎的标杆
• 各企业内部知识库问答系统 普遍采用类似架构
• LangChain / LlamaIndex 等框架将 RAG 标准化、工程化

从技术演进角度看，searchGPT 的局限性（依赖 Bing API、单点 LLM 调用、无异步处理）也反映了早期 LLM 应用的共同瓶颈，这些问题在后继框架中逐步得到解决。

searchGPT 的 Web UI 界面，支持在线填写 API Key，直接发起问答

搜索结果附带来源编号，点击可跳转原始网页，确保答案可溯源