这次我们来看一个名为 PixelRAG 的开源项目，它提出了一种颠覆传统检索增强生成（RAG）思路的新方法。传统的 RAG 在处理包含大量图表、截图、公式或复杂排版的文档时，往往会因为 OCR 识别不准、文本提取丢失布局信息而“卡壳”，导致检索到的上下文不相关，最终生成错误答案。PixelRAG 的核心思路是“让 AI 不读字，只看图”——它直接将整个文档页面转换为图像，利用强大的多模态视觉语言模型（VLM）来理解和检索，准确率反而更高。

对于开发者、技术爱好者和需要处理复杂文档的从业者来说，PixelRAG 的价值在于它绕过了文本解析的诸多坑点，提供了一条更鲁棒的信息检索路径。它尤其适合处理学术论文、技术报告、财务报表、产品手册等富含非文本元素的资料。本文将带你快速了解 PixelRAG 的核心能力、部署方式，并通过实测演示其如何仅凭“看图”就能完成精准问答。

1. 核心能力速览

能力项 说明
项目类型 基于视觉语言模型（VLM）的检索增强生成（RAG）系统
核心创新 将文档页转为图像进行检索，避免 OCR/文本解析错误，提升对图表、公式、复杂排版文档的理解能力
处理流程 文档分页 → 转换为图像 → 使用 VLM 编码为向量 → 向量检索 → 大模型生成答案
关键模型 依赖 CLIP、BLIP 等视觉编码器，以及 LLaVA、Qwen-VL 等多模态大模型进行理解与生成
硬件门槛 主要取决于所选 VLM 模型。轻量级模型可在 CPU 或低显存 GPU（如 6G）上运行；大型 VLM 需要较高显存（如 16G+）
输入支持 PDF、PPT、Word、网页截图、扫描件等可转换为图像格式的文档
输出形式 自然语言答案，并可引用来源图像片段
部署方式 支持 Python 库本地集成、API 服务部署，可与现有 RAG 管道结合
适合场景 学术研究、技术文档问答、财务/法律文件分析、教育内容解析等需要高精度理解图文混合内容的场景

2. 适用场景与使用边界

PixelRAG 并非要取代所有传统 RAG，而是针对特定痛点提供了更优解。理解其适用边界，能帮你更好地判断是否该引入它。

它最适合这些场景：

  1. 文档富含非文本元素 ：当你的文档库中有大量包含图表、流程图、数学公式、化学结构式、代码截图、复杂表格的 PDF 或 PPT 时，传统文本 RAG 的检索质量会急剧下降，PixelRAG 的优势则非常明显。
  2. 文档来源多样，排版混乱 ：处理从不同渠道收集的扫描件、截图、排版不规范的报告时，OCR 效果不可控，PixelRAG 的图像检索方式更具鲁棒性。
  3. 对答案准确性要求极高 ：在金融分析、法律条文引用、学术文献调研等场景，检索上下文的相关性和完整性至关重要，PixelRAG 能提供更可靠的来源信息。

它可能不适用或需要调整的场景：

  1. 纯文本文档处理 ：如果文档全是规整的文字，没有图片，传统基于嵌入的文本 RAG 在速度和资源消耗上通常更有优势。
  2. 对实时性要求极高 ：图像编码和 VLM 推理通常比纯文本嵌入更耗时，在需要毫秒级响应的场景下，需要权衡精度与速度。
  3. 严格的数据隐私要求 ：虽然可以本地部署，但若使用云端大型 VLM API（如 GPT-4V），需考虑数据出域风险。务必使用本地或私有化部署的视觉模型。

合规与安全边界：

  • 版权与隐私 ：处理任何文档前，必须确保你拥有相应的使用权或已获得授权。不得使用 PixelRAG 处理受版权严格保护的书籍、未公开的机密文件或个人隐私信息。
  • 事实核查 ：AI 生成的内容可能存在“幻觉”。对于关键决策，必须对生成答案进行人工复核，并追溯其检索到的图像来源进行验证。

3. 环境准备与前置条件

在开始部署 PixelRAG 之前，需要准备好以下软硬件环境。由于 PixelRAG 是一个方法论或开源项目集合（具体实现可能因版本而异），以下给出通用性较强的准备清单。

基础运行环境：

  • 操作系统 ：Linux (Ubuntu 20.04+ 推荐)、Windows (WSL2 推荐) 或 macOS。
  • Python ：版本 3.8 至 3.11。建议使用虚拟环境（ venv 或 conda ）隔离依赖。
  • 包管理工具 ： pip 最新版。

硬件与驱动要求：

  • CPU ：现代多核 CPU（如 Intel i5/i7 或 AMD Ryzen 5/7 及以上）。
  • 内存 ：建议 16GB 或以上，处理大量文档图像时占用较高。
  • GPU（可选但推荐） ：用于加速视觉编码器和 VLM 推理。
    • NVIDIA GPU ：显存至少 6GB（用于轻量级 VLM 如较小的 LLaVA 变体）。如需运行更大的 VLM（如 Qwen-VL-Max），建议 16GB 以上显存。
    • 驱动与 CUDA ：确保安装与 PyTorch 版本匹配的 NVIDIA 驱动和 CUDA Toolkit（如 CUDA 11.8 或 12.1）。
  • 磁盘空间 ：至少预留 10-20GB 空间用于存放模型文件、文档图像和向量数据库。

关键依赖库： 核心依赖将围绕计算机视觉、深度学习框架和向量数据库。 

# 以下为示例性依赖，具体需根据 PixelRAG 实现代码确定
torch>=2.0.0
torchvision
transformers>=4.35.0  # 用于加载视觉和语言模型
accelerate  # 用于模型加载优化
sentence-transformers  # 可能用于文本向量对比
pillow  # 图像处理
pdf2image  # 将 PDF 转换为图像
chromadb 或 faiss  # 向量数据库存储和检索
openai  # 如果使用 GPT-4V 等云端 API

模型文件准备： 你需要提前下载或准备好视觉编码器和 VLM 模型。例如：

  • 视觉编码器 ： openai/clip-vit-base-patch32 或 Salesforce/blip2-opt-2.7b
  • VLM（视觉语言模型） ： llava-hf/llava-1.5-7b-hf 或 Qwen/Qwen-VL-Chat

这些模型通常可通过 Hugging Face Hub 下载，首次运行时会自动缓存，但建议在网络通畅时提前下载。

4. 安装部署与启动方式

假设我们基于一个典型的 PixelRAG 开源实现（例如一个集成了 CLIP 编码器和 Chroma 向量数据库的 Python 项目）进行部署。以下是通用的步骤。

步骤一：克隆项目与创建环境 

# 1. 克隆项目仓库（此处以示例仓库为例，实际请替换为正确的 URL）
git clone https://github.com/example/pixelrag.git
cd pixelrag

# 2. 创建并激活 Python 虚拟环境
python -m venv venv
# Linux/macOS
source venv/bin/activate
# Windows
venv\Scripts\activate

# 3. 安装项目依赖
pip install -r requirements.txt

步骤二：配置模型与参数 在项目根目录下，通常会有配置文件（如 config.yaml 或 config.py ）。你需要根据你的硬件和需求进行调整。 

# config.yaml 示例
model:
  visual_encoder: "openai/clip-vit-base-patch32" # 视觉编码器模型名
  vlm_model: "llava-hf/llava-1.5-7b-hf" # 视觉语言模型名
  text_embedding_model: "sentence-transformers/all-MiniLM-L6-v2" # （可选）文本编码器，用于混合检索
  device: "cuda:0" # 或 "cpu"
  load_in_8bit: true # 是否使用 8bit 量化以节省显存

data:
  document_dir: "./docs" # 原始文档存放目录
  image_dir: "./images" # 转换后的图像临时目录
  chunk_size: 1 # 每页图像作为一个 chunk

vector_db:
  type: "chroma" # 向量数据库类型
  persist_directory: "./chroma_db" # 向量数据库持久化路径

retrieval:
  top_k: 3 # 检索返回的最相关片段数量

generation:
  api_base: "http://localhost:8000/v1" # 如果使用本地 LLM API
  model_name: "gpt-4" # 或本地模型名
  temperature: 0.1

步骤三：启动文档索引服务（后端） 索引服务负责将文档转换为图像并存入向量数据库。 

# 方式1：直接运行索引脚本
python scripts/index_documents.py --config config.yaml

# 方式2：如果项目提供了 API 服务，启动索引 API
python api/indexing_api.py --host 0.0.0.0 --port 8001

运行索引后，你的文档会被处理，并在 ./chroma_db 目录下生成向量数据库文件。

步骤四：启动问答服务（前端/API） 问答服务提供检索和生成答案的接口。 

# 方式1：启动简单的 WebUI（如果项目提供）
python app.py

# 方式2：启动问答 API 服务
python api/qa_api.py --host 0.0.0.0 --port 7860

启动成功后，通常可以通过浏览器访问 http://localhost:7860 打开 Web 界面，或通过 http://localhost:7860/api/chat 调用 API。

5. 功能测试与效果验证

部署完成后，我们需要系统性地测试 PixelRAG 的核心功能。我们从最简单的纯文本问答开始，逐步过渡到其擅长的图文混合问答。

5.1 测试一：纯文本文档问答（基线测试）

测试目的 ：验证系统在理想文本情况下的基础检索与生成能力。

  1. 准备文档 ：将一个纯文本的 PDF 文件（例如一篇技术博客的导出 PDF）放入 ./docs 目录。
  2. 构建索引 ：运行索引脚本，观察日志是否成功将 PDF 分页、转图像、编码并存入向量库。
  3. 提出问题 ：通过 WebUI 或 API 提出一个文档中明确包含答案的问题。
    • 输入问题 ：“本文中提到的核心架构是什么？”
    • 操作 ：在 WebUI 输入框提问，或调用 API： 
    curl -X POST http://localhost:7860/api/chat \
  -H "Content-Type: application/json" \
  -d '{
    "question": "本文中提到的核心架构是什么？",
    "history": []
  }'
  4. 预期结果与判断 ：
    • 成功 ：系统返回的答案准确引用了文档内容，并且答案本身是通顺、合理的。
    • 观察点 ：同时关注系统是否返回了检索到的“来源图像”或图像片段 ID。这证明了其检索机制是基于图像向量进行的。

5.2 测试二：图表密集型文档问答（核心能力测试）

测试目的 ：验证 PixelRAG 在处理传统 RAG 易出错的图表文档时的优势。

  1. 准备文档 ：找一个包含复杂流程图、柱状图、饼图的 PPT 或 PDF（例如一份市场分析报告）。
  2. 重新索引 ：将新文档放入 ./docs ，再次运行索引（或确保索引服务支持增量添加）。
  3. 提出基于图表的问题 ：
    • 问题示例1（数据查询） ：“根据第三页的柱状图，2023年Q4的销售额是多少？”
    • 问题示例2（流程理解） ：“请描述图2所示的用户注册流程。”
  4. 效果验证 ：
    • 准确性 ：对比 AI 生成的答案与图表中的真实数据或流程描述是否一致。
    • 优势体现 ：传统文本 RAG 可能因为 OCR 无法识别图表中的文字而失败，或错误地将图表标题文本与问题匹配。PixelRAG 应能正确理解图像内容，给出精准答案。你可以通过关闭系统的“视觉编码”功能（如果支持），仅用文本编码进行对比测试，直观感受差异。

5.3 测试三：公式与代码截图文档问答

测试目的 ：验证系统对数学公式、代码片段的识别与理解能力。

  1. 准备文档 ：使用包含复杂数学公式（LaTeX 渲染）或代码截图的学术论文 PDF。
  2. 索引并提问 ：
    • 问题示例1（公式） ：“请解释论文中公式 (5) 的物理含义。”
    • 问题示例2（代码） ：“截图中的 Python 函数实现了什么算法？”
  3. 判断标准 ：生成的答案不应是简单重复公式或代码，而应能结合上下文进行解释。这考验了 VLM 的深层理解能力。

5.4 测试四：多文档混合检索

测试目的 ：测试系统在多个文档中检索相关信息并综合回答的能力。

  1. 准备多个相关文档 ：例如，三份不同年份的同一公司财报 PDF。
  2. 一次性索引所有文档 。
  3. 提出综合性问题 ：“对比过去三年该公司在研发投入上的变化趋势。”
  4. 预期结果 ：答案应能综合多份文档中图表和数据，给出趋势性描述，并可能指出具体年份和数值。

6. 接口 API 与批量任务

对于生产环境，通过 API 集成和批量处理能力至关重要。PixelRAG 项目通常提供相应的接口。

RESTful API 调用示例： 假设问答 API 运行在 http://localhost:7860 。 

import requests
import json
import base64

class PixelRAGClient:
    def __init__(self, base_url="http://localhost:7860"):
        self.base_url = base_url

    def chat(self, question, history=None, top_k=3):
        """发送问题并获取答案"""
        url = f"{self.base_url}/api/chat"
        payload = {
            "question": question,
            "history": history or [],
            "top_k": top_k
        }
        try:
            response = requests.post(url, json=payload, timeout=60)
            response.raise_for_status()
            return response.json()
        except requests.exceptions.RequestException as e:
            print(f"API请求失败: {e}")
            return None

    def get_retrieved_images(self, response_data):
        """从响应中解析检索到的图像信息（假设返回图像ID或base64）"""
        # 实际响应结构需根据API定义调整
        retrieved = response_data.get("retrieved_chunks", [])
        for chunk in retrieved:
            image_id = chunk.get("image_id")
            score = chunk.get("score")
            # 可能包含获取图像内容的端点
            print(f"相关图像 ID: {image_id}, 相关性分数: {score:.4f}")

# 使用示例
if __name__ == "__main__":
    client = PixelRAGClient()
    result = client.chat("请总结文档中关于机器学习模型部署的挑战。")
    if result:
        print(f"答案: {result.get('answer')}")
        client.get_retrieved_images(result)

批量任务处理： 对于需要处理大量文档的场景，可以编写脚本进行批量索引和问答。 

import os
from concurrent.futures import ThreadPoolExecutor
import logging

logging.basicConfig(level=logging.INFO)
def batch_index_documents(doc_folder, config_path):
    """批量索引文件夹内所有文档"""
    supported_ext = ['.pdf', '.pptx', '.docx', '.png', '.jpg']
    for root, dirs, files in os.walk(doc_folder):
        for file in files:
            if any(file.lower().endswith(ext) for ext in supported_ext):
                doc_path = os.path.join(root, file)
                logging.info(f"开始索引: {doc_path}")
                # 这里调用项目的索引函数或子进程
                # 例如：subprocess.run(['python', 'index_single.py', '--doc', doc_path, '--config', config_path])
                # 注意错误处理和重试机制

def batch_qa_from_csv(question_csv, output_csv, client):
    """从CSV读取问题，批量获取答案并保存"""
    import pandas as pd
    df = pd.read_csv(question_csv)
    answers = []
    for idx, row in df.iterrows():
        q = row['question']
        logging.info(f"处理问题 {idx+1}: {q}")
        result = client.chat(q)
        answer = result.get('answer', '') if result else 'ERROR'
        answers.append(answer)
        # 可选：保存检索到的图像ID
    df['answer'] = answers
    df.to_csv(output_csv, index=False)
    logging.info(f"批量问答完成，结果已保存至 {output_csv}")

关键建议：

  • 限流与重试 ：在批量调用 API 时，添加适当的延时和重试逻辑，避免服务过载。
  • 结果校验 ：对于关键任务，应对批量生成的结果进行抽样校验。
  • 异步处理 ：对于极大量的文档，考虑使用消息队列（如 Redis、RabbitMQ）进行异步索引和问答任务分发。

7. 资源占用与性能观察

PixelRAG 的性能瓶颈主要出现在两个阶段： 文档索引（编码） 和 问答（检索+生成） 。了解资源占用有助于合理规划硬件和优化流程。

1. 索引阶段资源占用：

  • CPU/内存 ：将 PDF 转换为图像（ pdf2image ）是 CPU 密集型任务，处理大量页面时内存占用会显著上升。建议监控系统内存，必要时分批次处理文档。
  • GPU 显存 ：视觉编码器（如 CLIP）进行图像向量化时占用主要显存。 clip-vit-base-patch32 模型在批量处理图像时，显存占用与批量大小（batch size）正相关。
    • 观察命令 ：在 Linux 下可使用 nvidia-smi 或 gpustat 实时查看。
    • 优化 ：在配置文件中减小 batch_size 参数，或启用 load_in_8bit / load_in_4bit 量化。
  • 磁盘 I/O ：存储临时图像和向量数据库文件会产生大量磁盘写入。建议使用 SSD 硬盘。

2. 问答阶段资源占用：

  • 检索速度 ：从向量数据库（如 Chroma）中检索 top-k 个相似图像向量，速度很快，主要消耗 CPU 和少量内存。
  • VLM 推理 ：这是最耗资源的步骤。当用户提问后，系统需要将检索到的图像和问题一起输入 VLM（如 LLaVA）生成答案。
    • 显存峰值 ：VLM 加载和推理时显存占用达到峰值。7B 参数的 LLaVA 模型，在 FP16 精度下可能需要 14GB 以上显存。使用量化（8bit/4bit）可大幅降低至 6-8GB。
    • 推理时间 ：生成一个答案的时间从几秒到数十秒不等，取决于模型大小、生成长度和硬件。

3. 性能优化建议：

  • 轻量化模型 ：在精度可接受的前提下，选择更小的视觉编码器和 VLM 模型。
  • 量化 ：务必使用 bitsandbytes 库进行 8-bit 或 4-bit 量化，这是降低显存占用最有效的手段。
  • 缓存 ：对已索引的文档库，向量检索结果可以适当缓存，避免相同问题重复触发 VLM 推理。
  • 分离服务 ：将索引服务、向量数据库、VLM 推理服务部署在不同容器或进程中，实现资源隔离和水平扩展。

8. 常见问题与排查方法

在部署和运行 PixelRAG 过程中，你可能会遇到以下典型问题。这里提供排查思路。

问题现象 可能原因 排查方式 解决方案
导入错误：缺少模块 依赖未安装或版本冲突 检查 requirements.txt 和 pip list 创建干净的虚拟环境，严格按 requirements.txt 安装
CUDA out of memory 显存不足，模型或批量过大 运行 nvidia-smi 查看显存占用 1. 减小配置中的 batch_size 。
2. 启用 load_in_8bit=True 。
3. 换用更小的模型。
4. 使用 CPU 模式（ device=“cpu” ），但速度慢。
索引时 PDF 转换失败 pdf2image 依赖的 poppler 未安装 查看错误日志是否提示 poppler Linux: sudo apt-get install poppler-utils
Mac: brew install poppler
Windows: 下载 poppler 并将 bin 目录加入 PATH
启动 API 服务后端口被占用 端口 7860 或 8000 已被其他程序使用 netstat -ano | findstr :7860 (Win) 或 lsof -i:7860 (Linux/Mac) 修改启动命令中的端口号，如 --port 7861
检索结果完全不相关 1. 视觉编码器模型不匹配
2. 文档未正确转换为图像
3. 向量数据库未成功写入 		1. 检查 config 中模型名称。
2. 查看 ./images 目录是否有生成的图片。
3. 检查向量数据库目录是否有文件。 		1. 确认使用与训练数据相似的编码器（如 CLIP）。
2. 手动验证 PDF 转图像是否清晰可读。
3. 重新运行索引，观察日志是否有错误。
VLM 生成答案质量差（胡言乱语） 1. VLM 模型加载错误
2. 图像输入格式不对
3. 提示词（Prompt）设计不佳 		1. 检查 VLM 模型下载是否完整。
2. 查看传入 VLM 的图像张量尺寸和归一化是否正确。
3. 检查系统 prompt 是否清晰定义了任务。 		1. 删除缓存重新下载模型 ( ~/.cache/huggingface )。
2. 参考模型官方文档，确保图像预处理流程正确。
3. 优化 prompt，明确要求模型“根据提供的图片回答问题”。
API 调用超时 VLM 推理时间过长，超过默认超时设置 查看服务端日志，确认推理步骤耗时 1. 客户端增加超时时间（如 timeout=120 ）。
2. 服务端优化模型或使用更快的 VLM。
3. 实现异步任务，先返回任务 ID，再轮询结果。
无法处理中文文档 使用的 VLM 对中文支持不好 测试一个简单的中文图文问题 更换为支持中文的多模态模型，如 Qwen/Qwen-VL-Chat ，并在 prompt 中明确使用中文。

9. 最佳实践与使用建议

为了稳定、高效、合规地使用 PixelRAG，遵循以下最佳实践：

  1. 从小规模开始验证 ：不要一开始就索引数万份文档。选择 10-20 份具有代表性的文档（包含文本、图表、公式等）进行全流程测试，验证效果是否符合预期。
  2. 建立效果评估基准 ：针对你的业务问题，构建一个包含“问题-标准答案-文档来源”的小型测试集。在每次调整模型或参数后，用这个测试集评估准确率，做到心中有数。
  3. 文档预处理很重要 ：
    • 质量检查 ：确保源文档清晰。模糊的扫描件会影响图像编码质量。
    • 分页考虑 ：一页图像作为一个检索单元是否合理？对于超长图表，可能需要自定义分块逻辑。
    • 元数据注入 ：在索引时，能否将文档标题、作者、日期等元数据也存入向量库？这有助于在检索后阶段进行过滤和排序。
  4. 实现混合检索策略 ：PixelRAG 强在视觉，但纯文本检索也有其速度优势。考虑实现一个“混合检索器”，同时查询图像向量库和文本向量库，然后对结果进行重排序（Rerank），可能获得更全面的效果。
  5. 关注数据安全与隐私 ：
    • 本地部署 ：将视觉编码器和 VLM 模型完全部署在本地或私有服务器，确保敏感文档数据不出内网。
    • 访问控制 ：对提供的 WebUI 和 API 接口实施身份认证和权限控制。
    • 日志脱敏 ：避免在日志中完整记录用户提问和检索到的原始图像内容。
  6. 设计可维护的架构 ：
    • 将索引服务、向量数据库、推理服务、前端应用分离，便于独立升级和扩展。
    • 使用配置文件管理所有模型路径和参数，避免硬编码。
    • 为关键操作（如文档新增、删除、更新）设计完整的日志记录和监控告警。

10. 总结与下一步

PixelRAG 代表了一种解决复杂文档理解问题的新范式：当文字提取成为瓶颈时，直接让 AI“看图说话”可能是一条更高效的路径。它特别适合作为传统文本 RAG 系统的有力补充，用于处理那些让 OCR 和文本解析器“头疼”的文档。

最值得尝试的点 ：如果你手头的文档库中图表、公式、复杂排版的内容占比超过30%，那么引入 PixelRAG 的思路很可能带来检索准确率的显著提升。它的部署门槛与运行一个中等规模的视觉语言模型相当，对于已有 GPU 环境的团队来说，集成成本是可控的。

最先应该验证的功能 ：不要急于构建完整系统。第一步应该是用一两份最典型的图表文档，测试选定的视觉编码器（如 CLIP）能否将相似的图表聚类到正确的向量空间。这是整个流程的基石。

最容易踩的坑 ：模型版本不匹配和显存溢出。务必仔细核对 Hugging Face 上的模型卡（Model Card），确保下载的视觉编码器和 VLM 模型是兼容的。同时，量化是低显存显卡用户的必选项。

后续扩展方向 ：

  1. 自定义微调 ：如果你的文档领域非常特殊（如医学影像报告、工程图纸），可以考虑用领域数据对视觉编码器或 VLM 进行轻量微调（LoRA），以提升理解精度。
  2. 与工作流集成 ：将 PixelRAG 作为智能插件，嵌入到你的知识库系统、客服机器人或内部研究平台中，实现自动化文档问答。
  3. 探索多模态 RAG 前沿 ：关注 ImageBind、Fuyu 等统一的多模态嵌入模型，以及 GPT-4V、Gemini Pro Vision 等闭源 API 的最新能力，持续优化你的检索与生成管道。

建议将本文作为技术选型和初步实践的路线图。在实际部署时，深入阅读你所选用的具体 PixelRAG 实现项目的 README 和源码，是解决一切细节问题的关键。

# RAG
Logo
乐奇 Rokid 开放社区

更多推荐

芽芽：住在 AR 眼镜里的数字生态猫——基于 AIUI 的陪伴型智能体开发实战

芽芽 =人设（Persona）+ 三张Ink 页面。人设：温和治愈的小猫精，说话 1～2 句、适合语音朗读，永不索取隐私；页面：主页（陪伴与交互）、见闻页（照片记忆）、成长页（形态与图鉴）。

avatar 乐奇 Rokid 开放社区

手上全是油，我怎么让rokid眼镜在厨房里教我炒菜

打开应用就是食材页。屏幕上摆了 12 个常用芯片：鸡蛋、番茄、土豆、青椒、豆腐、鸡肉、猪肉、面条、米饭、青菜、黄瓜、香菇，滑到哪个点一下就选上了。也可以直接说话——在 Craft 调试时点右边麦克风唤醒，输入框打"辣椒炒肉拌面"发出去，它能自己拆出食材。一屏一步，大字显示当前在干嘛，上一步下一步靠镜腿滑动，需要等的步骤（比如"小火煮 3 分钟"）自带倒计时，到点自动语音念"第 n 步时间到"。整应

avatar 乐奇 Rokid 开放社区
cover

基于 Rokid AIUI：从一句咒语到一副眼镜，我做了款 AR 寻宝游戏《寻宝猎手》

avatar 乐奇 Rokid 开放社区