1. 项目概述：当搜索遇上大语言模型

最近在折腾一个挺有意思的开源项目，叫 searchGPT。这名字一看就懂，就是把传统的网络搜索和现在火得不行的大语言模型（LLM）给结合起来了。我干了这么多年技术，见过太多“搜索框+结果列表”的交互模式，用户得自己从一堆链接里筛选、归纳，效率其实挺低的。而 searchGPT 这个项目，它想干的事儿，说白了就是让 AI 来当你的“搜索助理”——你问一个问题，它不光帮你搜，还帮你把搜到的信息理解、整合、总结，最后给你一个结构清晰、有引用来源的答案。

这玩意儿解决的核心痛点，就是信息过载和认知负担。现在网上信息爆炸，搜个东西，前几页可能都是营销内容或者质量参差不齐的社区回答。普通用户，尤其是非技术背景的，很难快速辨别哪些信息是准确、相关、最新的。searchGPT 的思路是，把搜索结果的“阅读理解”和“信息提炼”工作，交给像 GPT 这样的 LLM 来完成。它背后通常集成了像 Google Search API 或 SerpAPI 这样的搜索服务，以及 OpenAI 的 GPT 系列模型（或者开源的替代品）。你输入查询，它先调用搜索 API 获取一批原始网页摘要或内容，然后把这些“原材料”喂给 LLM，并指令它：“基于这些资料，给我写一个答案，并且注明每句话是参考了哪个来源。”

这个项目非常适合几类人：一是内容创作者和研究者，需要快速调研某个话题并形成初步报告；二是开发者，想学习如何将外部 API（搜索、LLM）集成到一个连贯的应用流中；三是任何对提升信息获取效率感兴趣的普通用户。它不是一个简单的玩具，而是一个展示了“检索增强生成”（RAG）基础形态的绝佳实践案例。接下来，我就带你深入拆解它的设计思路、技术实现，以及我在部署和魔改过程中踩过的那些坑。

2. 核心架构与工作流拆解

要理解 searchGPT，不能光看表面功能，得把它拆开，看看数据是怎么流动的，各个组件之间如何协同。它的核心架构是一个典型的“搜索 -> 检索 -> 生成”流水线。

2.1 双引擎驱动：搜索与语言模型

这个项目的核心依赖于两个外部服务：一个 搜索服务 和一个 大语言模型服务 。

搜索服务负责从互联网海量信息中抓取与查询最相关的片段。常见的选择有：

  • Google Custom Search JSON API : 这是最直接的选择，提供稳定的搜索结果，包括标题、链接和摘要（snippet）。但它是付费服务，并且有每日查询限额。
  • SerpAPI : 一个聚合搜索结果的 API 服务，它帮你处理了不同搜索引擎的解析问题，返回结构化的数据。对于快速原型开发非常友好，同样也是付费的。
  • Bing Search API : 微软提供的替代方案。
  • 本地化/开源方案 : 对于有极高隐私要求或想完全免费的场景，可以考虑搭配 goose3 、 newspaper3k 这样的库，先获取链接，再直接抓取和解析网页正文。但这会复杂很多，涉及到反爬、解析稳定性等问题。

注意 ：使用这些商业搜索 API 时，务必仔细阅读其服务条款，特别是关于自动化查询和结果展示的规定。个人学习和小规模使用通常没问题，但商业化应用需要获得授权。

大语言模型服务是大脑，负责理解和生成。首选自然是 OpenAI 的 GPT 系列 API （如 gpt-3.5-turbo, gpt-4）。它的优势是效果稳定、API 易用。但缺点也很明显：按 token 收费，且所有查询数据会经过 OpenAI 的服务器。

因此，开源方案变得极具吸引力：

  • 本地部署模型 ：使用 ollama 、 LM Studio 或 text-generation-webui 在本地运行 Llama 3、Mistral、Qwen 等开源模型。这保证了数据的绝对私密性，且长期使用成本可能更低。但需要较强的硬件（GPU）支持，并且模型的理解和生成能力可能略逊于顶尖的闭源模型。
  • 兼容 OpenAI API 的本地服务 ：很多本地模型部署工具（如 ollama 、 vLLM ）提供了与 OpenAI API 兼容的端点。这意味着你几乎不用修改 searchGPT 中调用 LLM 的代码，只需把 API base URL 和 key 改成你本地服务的地址和一个虚拟密钥即可。这是平衡隐私、成本和便利性的好方法。

searchGPT 的巧妙之处在于，它通常设计为可配置的。你可以在配置文件中指定使用哪个搜索服务、哪个 LLM 服务，使得整个架构非常灵活。

2.2 工作流 Step-by-Step

让我们跟踪一次查询的完整生命周期：

  1. 查询接收与预处理 ：用户在前端界面（可能是一个简单的 Web 页面或命令行接口）输入问题，例如“Python 中如何高效地合并两个字典？”。应用后端接收到这个查询字符串。

  2. 搜索执行 ：后端根据配置，调用相应的搜索 API，将用户查询作为搜索关键词发送出去。例如，调用 Google Custom Search API，会返回一个 JSON 响应，里面包含10个左右的搜索结果项，每个项有 title , link , snippet 。

  3. 结果预处理与上下文构建 ：直接把这些原始的 snippet （通常只有一两句话）扔给 LLM 是不够的，信息量太单薄。因此，searchGPT 通常会有一个“内容增强”步骤。对于每个搜索结果链接，它可能会：

    • 直接使用 snippet （最快，但信息有限）。
    • 或者，更激进一些，使用像 requests + BeautifulSoup 这样的库去抓取链接指向的网页，提取主要的正文内容。这能获得更丰富的上下文，但速度慢，且容易遇到网站结构差异大、反爬虫等问题。 然后，它会将处理后的内容（标题+摘要或正文片段）与对应的链接一起，格式化成一段清晰的文本，作为“参考材料”。例如：
    [来源1] 标题: 《Python 合并字典的5种方法》
  链接: https://example.com/1
  内容: 在Python中，合并字典有多种方式，包括使用 update() 方法、{**d1, **d2} 语法、collections.ChainMap 等...
[来源2] 标题: 《详解 Python 3.9 的合并运算符 |》
  链接: https://example.com/2
  内容: Python 3.9 引入了字典合并运算符 (|)，使得合并操作更加直观和高效...

    所有这些参考材料会被拼接起来，但要注意总长度不能超过所选 LLM 模型的上下文窗口限制（比如 gpt-3.5-turbo 的 4096 token）。因此，这里通常需要做截断或智能选取。

  4. 提示词工程与 LLM 调用 ：这是核心中的核心。构建一个精心设计的“提示词”（Prompt），将用户查询和整理好的参考材料一起发送给 LLM。一个典型的提示词结构如下：

    你是一个有帮助的AI助手。请基于以下提供的网络搜索结果，回答用户的问题。
要求：
1. 答案必须完整、准确，并严格基于提供的资料。
2. 如果资料中的信息不足以回答问题，请如实说明。
3. 在答案中，为每一句重要的、源自资料的事实陈述，以[来源编号]的形式标注引用。
4. 答案最后，以“参考资料：”为标题，列出所有被引用到的来源的完整标题和URL。

网络搜索结果：
[此处插入上一步整理好的所有参考材料文本]

用户问题：{用户输入的问题}

    这个提示词明确了 LLM 的角色、任务、格式要求（引用和参考资料列表），这是获得高质量、可溯源答案的关键。然后，调用 LLM API，发送这个提示词。

  5. 答案解析与呈现 ：LLM 返回生成的答案文本。后端需要解析这个文本，通常答案中会包含 [1] , [2] 这样的标记。前端界面在渲染时，可以将这些标记渲染成可点击的上标，点击后平滑滚动到页面底部的“参考资料”列表，或者直接显示 tooltip。最终，用户看到一个有引用、有出处的完整答案，而不是一堆需要自己点击的蓝色链接。

3. 从零开始部署与关键配置

了解了原理，手痒想自己搭一个吧？我们以最经典的组合为例： SerpAPI（搜索） + OpenAI GPT-3.5-Turbo（LLM） ，部署一个基础版的 searchGPT。这里假设你已经有基本的 Python 和命令行环境。

3.1 环境准备与依赖安装

首先，你需要准备两把“钥匙”：

  1. SerpAPI 密钥 ：去 serpapi.com 注册，可以在免费额度内试用。
  2. OpenAI API 密钥 ：去 platform.openai.com 注册并获取。

然后，克隆项目（以原版 michaelthwan/searchGPT 为例，但请注意其可能更新，以下步骤是通用逻辑）并安装依赖。

# 克隆项目代码
git clone https://github.com/michaelthwan/searchGPT.git
cd searchGPT

# 创建并激活 Python 虚拟环境（强烈推荐，避免包冲突）
python -m venv venv
# Windows:
venv\Scripts\activate
# Linux/Mac:
source venv/bin/activate

# 安装项目依赖，通常需要手动安装或根据 requirements.txt
pip install openai serpapi requests streamlit

原项目可能使用其他框架（如 FastAPI），这里我以 streamlit 为例，因为它能极快地构建交互式 Web 应用，适合演示和轻量级使用。

3.2 核心代码实现解析

我们来写一个最简化的核心逻辑文件 app.py ：

import os
import streamlit as st
from serpapi import GoogleSearch
import openai

# 从环境变量或Streamlit secrets加载API密钥
openai.api_key = st.secrets["OPENAI_API_KEY"]
serpapi_key = st.secrets["SERPAPI_KEY"]

def search_web(query):
    """使用SerpAPI执行搜索"""
    params = {
        "engine": "google",
        "q": query,
        "api_key": serpapi_key,
        "num": 5  # 获取5个结果，控制上下文长度
    }
    search = GoogleSearch(params)
    results = search.get_dict()
    organic_results = results.get("organic_results", [])
    
    formatted_results = []
    for idx, res in enumerate(organic_results):
        # 提取标题、链接和摘要
        title = res.get('title', '')
        link = res.get('link', '')
        snippet = res.get('snippet', '')
        # 格式化每个来源
        formatted_results.append(f"[来源{idx+1}] 标题: {title}\n链接: {link}\n摘要: {snippet}\n")
    return formatted_results

def generate_answer(query, contexts):
    """调用OpenAI GPT模型生成答案"""
    # 构建上下文文本
    context_text = "\n---\n".join(contexts)
    
    # 精心设计的系统提示词
    system_prompt = """你是一个准确、有帮助的AI助手。请严格根据用户提供的网络搜索结果来回答问题。
回答要求：
1. 答案必须基于提供的资料。如果资料不足，请说明。
2. 答案中的关键事实陈述，必须使用[来源编号]进行标注。
3. 在答案末尾，列出所有引用到的参考资料，格式为：`[编号] 标题 - URL`。
"""
    user_prompt = f"网络搜索结果：\n{context_text}\n\n用户问题：{query}"
    
    try:
        response = openai.ChatCompletion.create(
            model="gpt-3.5-turbo",
            messages=[
                {"role": "system", "content": system_prompt},
                {"role": "user", "content": user_prompt}
            ],
            temperature=0.2,  # 较低的温度，让答案更确定、更基于事实
            max_tokens=1000   # 控制答案长度
        )
        return response.choices[0].message.content
    except Exception as e:
        return f"生成答案时出错：{e}"

# Streamlit 前端界面
st.title("🔍 searchGPT 演示")
user_query = st.text_input("请输入你的问题：", placeholder="例如：如何学习Python？")

if user_query:
    with st.spinner("正在搜索网络并生成答案..."):
        # 步骤1: 搜索
        search_results = search_web(user_query)
        # 步骤2: 生成
        answer = generate_answer(user_query, search_results)
        
    st.subheader("🤖 AI 生成的答案")
    st.markdown(answer)
    
    # 可选：展示原始搜索结果
    with st.expander("查看原始搜索结果"):
        for res in search_results:
            st.text(res)

这个代码不到100行，但完整实现了核心流程。 search_web 函数获取并格式化搜索结果， generate_answer 函数构建提示词并调用 GPT。前端用 Streamlit 几行代码就搞定。

3.3 配置与运行

  1. 将你的 API 密钥保存在一个安全的地方。对于 Streamlit，可以创建 .streamlit/secrets.toml 文件： 
    OPENAI_API_KEY = "sk-你的openai密钥"
SERPAPI_KEY = "你的serpapi密钥"
  2. 运行应用： 
    streamlit run app.py
    浏览器会自动打开，你就能看到一个简单的搜索问答界面了。

实操心得 ：在第一次运行前，务必先单独测试你的两个 API 密钥是否有效。可以写个几行的小脚本，分别调用 SerpAPI 和 OpenAI，确保网络和计费没问题。很多部署失败就卡在这第一步。

4. 进阶优化与定制化改造

基础版跑通了，但你会发现它有点“笨”。比如，搜“最新的 Python 版本特性”，它可能给你一篇2021年的博客。或者答案里引用了不相关的来源。这就需要我们进行优化。

4.1 提升搜索质量：超越基础摘要

原始搜索结果的 snippet 往往只是页面的一小段摘录，信息不完整。我们可以引入轻量级的网页内容提取。

  • 方案一：使用 Readability 类库 ：像 goose3 或 trafilatura 这样的库，专门用于提取网页正文，去除广告、导航等噪音。这能显著增加上下文的信噪比。

    import trafilatura
def fetch_article_content(url):
    downloaded = trafilatura.fetch_url(url)
    content = trafilatura.extract(downloaded)
    return content[:2000]  # 截取前2000字符，避免过长

    然后在 search_web 函数中，对于每个结果的 link ，可以尝试调用 fetch_article_content 来获取更详细的内容，替代 snippet 。 注意 ：这会使搜索过程变慢（需要串行抓取多个页面），并且必须尊重网站的 robots.txt 和版权。仅适用于个人学习和研究。

  • 方案二：结果过滤与排序 ：不是所有搜索结果都同等重要。可以引入简单的启发式规则：

    • 域名权重 ：优先考虑 stackoverflow.com , docs.python.org , github.com 等技术内容集中的网站。
    • 时间感知 ：在查询中隐含时间要求，例如搜索时加上“2023 2024”等关键词，或者尝试解析搜索结果中的日期信息（如果API提供）。
    • 相关性重排序 ：将用户查询和每个搜索结果的 title + snippet 转换成向量（用 sentence-transformers 等库），计算余弦相似度，只保留最相关的3-4个结果给 LLM。这能有效防止上下文被无关信息污染。

4.2 提示词工程的精雕细琢

提示词直接决定了 LLM 的产出质量。除了基础格式，还可以加入更多指令：

你是一个严谨的技术信息助手。请基于以下提供的网络搜索结果，回答用户的技术问题。
指令：
1. **准确性优先**：答案必须严格基于资料。如果资料间有冲突，指出冲突并说明主要观点。
2. **引用规范**：每个独立的事实、数据、方法步骤，都必须用[来源X]标注。一句内引用多个来源用[来源X][来源Y]。
3. **结构化输出**：如果问题涉及步骤、列表或对比，请使用Markdown格式（如编号列表、**加粗**）组织答案，使其清晰易读。
4. **不确定性声明**：如果某个关键点在资料中未找到明确依据，请说明“根据现有资料，未找到明确支持...”。
5. **参考资料清单**：在“### 参考资料”标题下，列出所有被引用的来源，格式为：`[X] [页面标题](URL)`。

提供的搜索结果：
{context}

问题：{query}

这样的提示词能引导 LLM 生成更专业、结构更佳、且引用更精确的答案。

4.3 转向开源与本地化部署

使用 OpenAI API 总有数据隐私和成本的顾虑。迁移到本地模型是必然的探索。

  1. 使用 Ollama 本地运行模型 ：

    # 安装 Ollama (Mac/Linux)
curl -fsSL https://ollama.com/install.sh | sh
# 拉取一个模型，例如 Llama 3 8B
ollama pull llama3:8b
# 启动服务，默认在 11434 端口提供兼容OpenAI的API
ollama serve

    Ollama 启动后，会提供一个 http://localhost:11434 的端点。

  2. 修改代码，指向本地端点 ：

    import openai
openai.api_base = "http://localhost:11434/v1"  # 关键：修改API基础地址
openai.api_key = "ollama"  # 本地部署不需要真密钥，但需要填一个非空值

def generate_answer_local(query, contexts):
    context_text = "\n---\n".join(contexts)
    # 提示词可能需要针对本地模型微调，例如更简洁
    prompt = f"基于以下信息回答问题：\n{context_text}\n\n问题：{query}\n答案（请引用[来源号]）："
    
    try:
        # 注意，模型名要改成 ollama 中拉取的模型名
        response = openai.ChatCompletion.create(
            model="llama3:8b", # 使用本地模型名
            messages=[{"role": "user", "content": prompt}],
            temperature=0.2,
            max_tokens=800,
            stream=False  # 本地可能关闭流式
        )
        return response.choices[0].message.content
    except Exception as e:
        return f"本地模型生成错误：{e}"

    这样，你的 searchGPT 就完全在本地运行了，数据不出你的机器。代价是生成速度可能慢一些，且模型的知识截止日期是固定的（训练数据的时间），无法获取最新信息，这就更凸显了与搜索结合的必要性。

5. 常见问题、性能调优与避坑指南

在实际搭建和使用过程中，你会遇到各种各样的问题。我把它们整理出来，希望能帮你少走弯路。

5.1 典型错误与排查表

问题现象 可能原因 排查步骤与解决方案
搜索无结果或报错 1. API 密钥无效或过期。
2. 搜索 API 服务额度用尽或配置错误。
3. 网络问题（代理设置）。		 1. 单独运行一个测试脚本验证 API 密钥。
2. 登录 SerpAPI/Google Cloud 控制台检查用量和配置（如是否启用了 Custom Search API）。
3. 检查 Python 环境是否配置了正确的网络代理（ requests 库可通过 proxies 参数设置）。
LLM 不生成答案或报超时 1. OpenAI API 密钥问题或额度不足。
2. 提示词过长，超出模型上下文限制。
3. 本地模型服务未启动或崩溃。
4. 网络连接问题。		 1. 检查 OpenAI 账户余额和速率限制。
2. 计算提示词 token 数（可用 tiktoken 库），减少搜索返回的结果数量 ( num 参数) 或截断网页内容。
3. 检查 ollama ps 或本地服务进程状态，查看日志。
4. 用 curl 测试本地 API 端点是否可达。
答案质量差，胡言乱语 1. 提示词设计不佳，指令不明确。
2. 搜索返回的上下文质量太低（垃圾信息多）。
3. 模型能力不足（特别是小参数本地模型）。
4. Temperature 参数过高，导致随机性大。		 1. 迭代优化提示词，加入更明确的角色、格式和约束指令。
2. 实现搜索结果过滤（如前文的域名权重、相关性排序）。
3. 尝试更大的模型（如 llama3:70b ），或换用闭源 API。
4. 将 temperature 调低至 0.1-0.3 范围。
答案中没有引用或引用混乱 1. 提示词中关于引用的指令不够强硬或清晰。
2. 上下文格式混乱，模型无法区分不同来源。		 1. 在提示词中强调“ 必须 引用”、“ 严格 按照格式”。
2. 确保格式化上下文时，每个来源之间有清晰的分隔符（如 \n---\n ），并且来源编号 [来源X] 醒目。
应用响应速度极慢 1. 串行抓取网页内容。
2. 本地模型推理速度慢。
3. 网络延迟高。		 1. 使用 asyncio + aiohttp 异步并发抓取网页（如果实施了抓取）。
2. 对于本地模型，考虑使用量化版本（如 llama3:8b-instruct-q4_K_M ），或升级硬件。
3. 优化搜索 num 参数，在质量和速度间权衡。

5.2 性能与成本优化实战

  • 上下文长度是核心瓶颈 ：GPT-3.5-Turbo 有 16K 上下文版本，但更贵。对于大多数问答，5-8个搜索结果，每个结果提供300-500字的上下文，通常足够。务必在代码里计算 token 或字符数，并做好截断。

    def truncate_contexts(contexts, max_chars=6000):
    """简单按字符截断上下文"""
    total_len = sum(len(c) for c in contexts)
    if total_len <= max_chars:
        return contexts
    # 简单策略：按比例截断每个上下文
    ratio = max_chars / total_len
    truncated = []
    for ctx in contexts:
        truncated.append(ctx[:int(len(ctx)*ratio)])
    return truncated

  • 缓存策略 ：对于相同或相似的查询，没必要重复搜索和调用 LLM，这既慢又费钱。可以引入一个简单的缓存，例如使用 functools.lru_cache 缓存函数结果，或者用 Redis 缓存序列化后的答案。键可以是查询字符串的哈希值。

    from functools import lru_cache
@lru_cache(maxsize=100)
def cached_search_and_answer(query):
    # 原有的搜索生成逻辑
    results = search_web(query)
    answer = generate_answer(query, results)
    return answer

    注意：对于时效性强的查询（如“今天天气”），需要设置缓存过期或绕过缓存。

  • 异步化改造 ：这是提升用户体验的关键。搜索和 LLM 调用都是网络 I/O 密集型操作，使用异步可以避免界面“卡死”。

    import asyncio
import aiohttp
from openai import AsyncOpenAI

# 使用支持异步的客户端
aclient = AsyncOpenAI(api_key=api_key)

async def async_generate_answer(query, contexts):
    # 异步调用 OpenAI API
    response = await aclient.chat.completions.create(
        model="gpt-3.5-turbo",
        messages=[...],
        temperature=0.2
    )
    return response.choices[0].message.content

# 在 Streamlit 中，可以使用 asyncio.run() 或在异步框架中处理

5.3 安全与伦理考量

自己搭建这样一个工具，乐趣无穷，但也要担起责任。

  1. 内容可靠性 ：LLM 会“幻觉”，即生成看似合理但完全错误的信息。即使有引用，也可能错误关联。 绝对不能 将此类系统生成的内容作为医疗、法律、金融等关键决策的唯一依据。必须在界面显眼位置添加免责声明。
  2. 版权与数据抓取 ：如果你实施了网页内容抓取，必须遵守 robots.txt 协议，控制抓取频率，避免对目标网站造成负担。对于商业用途，务必谨慎。
  3. API 使用合规 ：严格遵守 OpenAI、Google 等平台的 API 使用条款。不要将其用于生成垃圾邮件、虚假信息、恶意软件等非法或有害用途。
  4. 用户隐私 ：如果你的应用部署在公网，会接收到用户的查询。要明确告知用户数据将如何被使用（例如，查询会发送给第三方 API），最好提供隐私政策。如果使用本地模型，这一点优势巨大。

6. 扩展思路：从玩具到工具

一个基础的 searchGPT 已经能解决不少问题，但我们可以让它变得更强大、更专用。

  • 垂直领域搜索助手 ：替换通用的搜索引擎为垂直领域的数据库或 API。比如，做一个“法律条文搜索助手”，将搜索后端换成法律数据库的 API；做一个“内部文档问答”，利用向量数据库（如 ChromaDB, Weaviate）存储公司内部文档，通过语义搜索召回相关片段，再交给 LLM 生成答案。这就演变成了一个标准的 RAG 系统。

  • 多轮对话与记忆 ：现在的 searchGPT 是单轮的。可以引入对话历史管理。将之前的问答对也作为上下文的一部分（在长度允许的情况下）提供给 LLM，让它能进行指代消解和连贯对话。这需要设计更复杂的状态管理。

  • 溯源增强与可信度评分 ：不仅显示引用，还可以尝试对每个引用的来源进行“可信度”评估（例如，权威网站得分高，个人博客得分低），并在答案中体现。甚至可以尝试让 LLM 对答案中不同部分的置信度进行自我评估。

  • 结果可视化 ：对于涉及数据、比较的查询，可以尝试让 LLM 在答案中输出结构化的数据（如 JSON），然后前端用图表（如 matplotlib, plotly）渲染出来。例如，问“比较 Python、Java、Go 在2023年的流行度”，LLM 从资料中提取数据，生成一个简短的比较表格或趋势描述。

折腾 searchGPT 这类项目，最大的收获不是做出了一个多么厉害的产品，而是亲手实践并理解了“检索增强生成”（RAG）这套当前最主流的让 LLM 获取新知识、减少幻觉的架构范式。从配置 API 密钥时的小心翼翼，到看到第一个带引用的答案生成时的兴奋，再到优化提示词、处理各种边界错误时的抓狂，最后到成功切换到本地模型后的那种“一切尽在掌控”的踏实感，这个过程本身就是对现代 AI 应用开发一次极好的全景式体验。

我个人的体会是，开始的时候不要追求大而全，就用最少的代码把核心流程跑通，获得正反馈。然后，再像搭积木一样，一个一个地解决你遇到的具体问题：速度慢就加缓存，答案不准就调提示词，想保护隐私就换本地模型。每一个问题的解决，都会让你对背后的技术有更深一层的理解。最后，别忘了给它加个好看点的前端，毕竟，能分享给别人用的工具，才是真正有生命力的工具。

# RAG
Logo
亚马逊云科技技术品牌专区

更多推荐

cover

Hugging Face Optimum 源码静态评测：模型部署优化框架的工程结构与验证边界

avatar 亚马逊云科技技术品牌专区
cover

单片机基础核心知识点汇总（十）

avatar 亚马逊云科技技术品牌专区
cover

白嫖192G显存GPU！ModelScope三种免费算力一篇讲清

avatar 亚马逊云科技技术品牌专区