PixelRAG 是 UC Berkeley（加州大学伯克利分校，Sky Computing Lab / BAIR）提出并开源的纯像素空间视觉RAG（Visual Retrieval-Augmented Generation）项目，论文标题《PIXELRAG: Web Screenshots Beat Text for Retrieval-Augmented Generation》，获 MLSys 2026 最佳论文，开源协议 Apache-2.0。
核心思想：不做HTML解析、不抽文本，直接把网页/PDF渲染成截图切片（tile），全程在图像像素空间完成检索+问答，完整保留版式、表格、图表、信息框等视觉结构，解决传统文本RAG解析时丢失布局信息的痛点。
StarTrail-org/PixelRAG，官网 pixelrag.ai；附带Claude Code插件（pixelbrowse），可直接在Claude Code中调用像素浏览检索能力。
7 个月前
在2026年开发AI产品时，搭建一个生产级（production-grade）RAG系统已经不再是“简单接个向量数据库就行”，而是需要系统性工程化思维。以下是从0到1再到生产可用的完整路径，按实际优先级和踩坑顺序组织。 一、生产级RAG ≠ Demo级RAG 的本质区别（2025-2026共识） 维度 Demo级（常见教程） 生产级（真正能上线赚钱） 为什么重要 文档量 几MB ~ 几百页 几万 ~ 几百万文档 / 多模态 / 每天增量更新 决定了分块、索引、召回策略完全不同 召回准确率 60-75% 目标88-95%+（视场景） 差10%召回率，用户体验天差地别 延迟 2-8秒随便 <1.5秒（p95），理想<800ms 用户流失率与延迟呈指数关系 幻觉控制 看运气 需要多重机制把幻觉率压到<5% 企业客户最怕胡说八道 可维护性 脚本跑一遍就行 需要数据质量pipeline、版本控制、监控告警 半年后没人敢碰代码 成本 不care embedding + LLM + vectorDB 每月几千到几十万刀 直接影响商业模式能否跑通 二、2026年主流生产级RAG搭建完整路径（推荐路线） Phase 0：先别写代码，先做这两件事（很多人跳过直接失败） 明确业务成功标准（最重要一步） 准确率目标：≥88%（RAGAS faithfulness & answer relevancy） 幻觉率：<5% 响应时间：p95 < 2秒（或按产品定位） 支持的文档类型：PDF/Word/Excel/网页/Markdown/扫描件/表格/图片？ 更新频率：实时 / 每天 / 每周？ 用户问题类型：单轮 / 多轮 / 带表格 / 需要推理？ 准备评估集（金标准） 至少200-500条 真实用户问题 + 人工标注的完美答案 后续所有优化都拿这个集子打分 Phase 1：数据摄入与预处理（决定天花板，占60%工作量） 现代顺序（2025-2026主流做法）： 文档清洗与质量分级（最被低估的一步） 运行一个轻量文档质量打分模型（或规则+小型LLM） 分三类：Clean / Decent / Garbage Garbage类直接人工干预或低权重处理 结构化解析（别直接喂Unstructured） PDF：用Marker / PyMuPDF + table detection（Marker 2025年后很强） Word/Excel：python-docx / pandas 保留层级：标题 → 段落 → 表格 → 图片说明 → 元数据 高级Chunk策略（2026年最核心差异化点） 策略 Chunk大小 适用场景 召回提升 Fixed-size 512 token 快速验证 baseline Semantic 200-800 主流生产 +15-25% Hierarchical 父子chunk 长文档、合同、手册 +20-35% Proposition-based 小粒度命题 法律/医疗/技术文档 +30%+ 推荐起步组合：Semantic + 父子索引 + 100-200 token重叠 Phase 2：Embedding 与 向量存储（2026主流选型） Embedding模型推荐（2026.2月时点性价比排序）： bge-m3 / Snowflake Arctic Embed（开源王者） voyage-3-large / Cohere embed-v4（闭源但效果顶尖） text-embedding-3-large（稳定但已被超越） 向量数据库主流选择： 场景 首选数据库 次选 备注 < 100万向量 Chroma / Qdrant本地 PGVector 开发快 100万-1亿 Qdrant / Milvus Weaviate Qdrant 2025-2026口碑最佳 亿级 + 高并发 Pinecone serverless Zilliz Cloud 省心但贵 极致私有化 pgvector + pgvectorscale Milvus standalone 强烈建议：hybrid search（dense + sparse / BM25）几乎成为2026标配。 Phase 3：检索与后处理（拉开差距的关键层） 现代检索流水线（2026主流）： 用户问题 ↓ Query分类与改写（是否需要检索？多意图拆分？） ↓ 多路召回（vector + BM25 + 知识图谱等） ↓ 初筛 top-30~100 ↓ 重排序（Cohere Rerank3 / bge-reranker-v2 / flashrank） ↓ 上下文压缩 / 抽取（LLM summarize top-8） ↓ 最终给LLM的上下文（带清晰source引用） Phase 4：生成与防幻觉 Prompt工程模板（必须有）： 强制要求：只用提供的内容回答 / 不知道就说不知道 / 标注来源 结构化输出（JSON）便于下游解析 防幻觉组合拳： Self-Check / Self-RAG Corrective RAG Groundedness check（RAGAS / TruLens） 后置事实核查（小模型或规则） Phase 5：评估、监控、迭代闭环（生产级灵魂） 必须上的指标： Retrieval：Recall@K, MRR, NDCG Generation：Faithfulness, Answer Relevancy, Context Precision/Recall End-to-End：用户打分 / A/B测试 / 业务指标（解决率、CSAT） 推荐工具组合（2026主流）： 评估：RAGAS / DeepEval / TruLens / Phoenix 监控：LangSmith / Helicone / Phoenix / PromptLayer Orchestration：LangGraph / LlamaIndex Workflows / Haystack / Flowise（低代码） 三、2026年推荐最小可用生产技术栈（性价比最高） 极简但能上线（适合小团队） 解析 → Marker / LlamaParse 向量化 → bge-m3 或 voyage-3 向量库 → Qdrant (docker) 召回+重排 → Qdrant + bge-reranker-v2 框架 → LlamaIndex 或 LangGraph LLM → DeepSeek-R1 / Qwen2.5-72B-Instruct / Claude-3.5-Sonnet (根据预算) 评估 → RAGAS + 人工golden set 进阶企业级（已验证可支撑十万+文档） 加：混合检索 + 父子索引 + query分解 + 多路召回 + 上下文压缩 + corrective RAG + 在线监控 一句话总结2026年RAG哲学： “70%的效果提升来自于数据质量、切块策略和检索后处理；20%来自embedding和重排序模型；只有10%靠换个更强的LLM。” 先把前70%做好，后面自然水到渠成。 （ Grok ）
7 个月前
AI Agent 的真正智能，来自于知识获取（RAG） + 协作协议（MCP） + 执行能力（SKILLS）的统一协同，而不是单一大模型孤立输出。
8 个月前
AI图片生成集成指南：从API到SDK的完整实现路径 在腾讯EdgeOne Pages模版详情页面点击“Deploy”按钮，填写必要的API密钥，点击“开始部署”——短短几分钟内，一个完整的AI图片生成应用就这样上线了。 随着人工智能技术的快速发展，AI图片生成功能已成为现代应用中不可或缺的一部分。无论是内容创作、产品设计还是营销素材制作，AI图片生成技术都能提供高效、创新的解决方案。 对于开发者而言，如何将这项能力快速、安全地集成到自己的应用中，成为了一个值得深入探讨的课题。 01 理解两种集成路径 原生API调用和AI SDK封装调用是当前将AI图片生成能力集成到应用中的两种主要技术路径，每种路径都有其独特的优势和应用场景。 原生API调用提供了精细控制和高度灵活性，开发者可以直接与底层API交互，定制化程度高。AI SDK则通过统一接口简化了开发流程，实现了多厂商模型的轻松切换。 以EdgeOne Pages为例，这两种集成方式都有对应的模版：ai-image-generator-starter用于原生接口调用，而ai-sdk-image-generator-starter则适用于AI SDK封装调用。 在开始集成之前，开发者需要根据自身需求选择合适的技术路径。对于追求控制和定制化的项目，原生API调用是更好的选择；而对于希望快速上线并支持多种模型的项目，AI SDK封装调用则更为合适。 02 快速入门：环境准备与部署 要实现AI图片生成功能，首先需要申请API Key。主流AI图片生成提供商的API Key获取地址包括： Hugging Face：huggingface.co/settings/tokens OpenAI：platform.openai.com/api-keys Replicate：replicate.com/account/api-tokens Fal：fal.ai/dashboard/keys Nebius：nebius.com/console 部署过程简单直观。以ai-sdk-image-generator-starter模版为例，在模版详情页面点击“Deploy”按钮，系统将跳转到EdgeOne Pages控制台。 在部署界面，开发者需要配置环境变量，这些配置项对应不同AI图片生成服务的API Key。不同模版会呈现不同的配置项列表，但必须确保至少有一个API Key配置正确且可用。 完成配置后点击“start deployment”按钮，项目就会开始自动部署。部署成功后，GitHub帐户下会生成一个与模版相同的项目，开发者可以通过git clone命令将其下载到本地进行进一步的开发和定制。 03 原生API调用详解 原生API调用方式让开发者能够精细控制每一个请求细节。在这一模式下，图片生成的基本流程是：前端发送生图参数到边缘函数，边缘函数调用AI模型API，最后将生成的图片返回给前端显示。 在前端部分，用户需要配置可用的AI模型列表。以src/pages/index.tsx文件中的核心代码为例： const res = await fetch("/v1/generate", { method: "POST", headers: { "Content-Type": "application/json", }, body: JSON.stringify({ image: `${prompt} (${modelInfo.name} style)`, platform: platform.id, model: modelInfo.value || selectedModel, }), }); 边缘函数的处理逻辑位于functions/v1/generate/index.js文件中。函数首先接收前端传递的参数，然后检查对应平台的环境变量是否配置正确。 const validateToken = (platform) => { const tokens = { nebius: env.NEBIUS_TOKEN, huggingface: env.HF_TOKEN, replicate: env.REPLICATE_TOKEN, openai: env.OPENAI_API_KEY, fal: env.FAL_KEY, }; if (!tokens) { throw new Error( `${platform} API token is not configured. Please check your environment variables.` ); } }; 这种通过env访问环境变量的方式，有效防止了API密钥在代码中明文暴露，提高了应用的安全性。敏感信息存储在环境变量中，而非硬编码在源代码里。 环境变量检查完成后，函数会直接请求对应平台的图片生成模型API。以HuggingFace为例，其标准API请求核心代码如下： const response = await PROVIDERS.fetch(url, { headers: { Authorization: `Bearer ${token}`, "Content-Type": "application/json", }, method: "POST", body: JSON.stringify(data), }); EdgeOne Pages的AI图片生成模版已经支持了多种主流模型，包括HuggingFace、OpenAI、Replicate、Fal、Nebius等。生成图片后，函数将结果返回给前端，模版项目内已经内置了图片显示的完整逻辑。 04 AI SDK封装调用解析 与原生API调用方式相比，AI SDK封装调用通过统一接口简化了开发流程。它允许开发者使用相同的代码结构调用不同厂商的AI图片模型，显著提高了开发效率和多模型切换的便利性。 在AI SDK方式下，前端通过/api/generate接口发送请求： const response = await fetch(apiUrl, { method: "POST", headers: { "Content-Type": "application/json", }, body: JSON.stringify({ prompt, model, size, }), }); 这里需要注意的是，size参数需要提前设置，因为不同的模型支持的尺寸列表可能不一致。 例如，DALL-E 3支持“1024x1024”、“1024x1792”、“1792x1024”等尺寸，而Stable Diffusion可能支持“512x512”、“768x768”等不同规格。 EdgeOne Pages的AI SDK图片生成模版已经梳理了AI SDK支持模型对应的尺寸列表，相关配置位于components/modelSizeMapping.ts文件中。开发者可以直接使用这些预配置的尺寸映射，无需手动处理不同模型的尺寸兼容性问题。 AI SDK同样避免了密钥泄漏风险。函数在调用AI图片模型时，使用AI SDK暴露的experimental_generateImage对象来统一生成图片内容，密钥的获取由experimental_generateImage在内部自动处理。 const imageResult = await experimental_generateImage({ model: imageModel, prompt: prompt, size: size, // Use frontend-provided size }); 调用experimental_generateImage后，只需要读取函数返回的标准格式内容即可： const imageUrl = `data:image/png;base64,${imageResult.image.base64}`; return new Response( JSON.stringify({ images: [ { url: imageUrl, base64: imageResult.image.base64, }, ], }) ); 05 本地调试与持续集成 开发者在下载项目到本地后，可能需要进行本地开发、调试或预览。为了简化本地环境配置，EdgeOne提供了专门的CLI工具。 使用EdgeOne CLI需要先安装并登录，具体步骤可以参考EdgeOne CLI的文档介绍。在安装和登录后，开发者可以在本地项目下执行edgeone pages link命令，将项目与EdgeOne Pages控制台的项目进行关联。 执行该命令后，系统会提示输入EdgeOne Pages的项目名，即上文部署的模版项目的项目名称。输入项目名后，EdgeOne Pages控制台的环境变量会自动同步到本地。 关联成功后，本地项目根目录下会生成.env文件，包含所有已配置的环境变量列表。关联后，可以执行edgeone pages dev命令来进行本地部署，部署后可以在localhost:8088进行访问。 对于代码的自定义修改，开发者可以直接通过git提交项目到GitHub。EdgeOne Pages会检测GitHub的提交记录并自动进行重新部署，实现真正的持续集成与持续部署。 部署完成后，控制台会显示部署状态和预览界面，开发者可以立即验证功能是否正常工作。 AI图片生成集成后的应用界面，简洁直观。模板提供了开箱即用的用户界面，用户可以直接输入提示词、选择模型和调整参数，生成结果会即时显示在右侧区域。 在本地测试过程中，如果对生成效果或性能有特定要求，开发者可以灵活切换不同的AI模型提供商。不同的模型在风格表现、细节处理等方面各有特色，有些专注于写实风格，有些擅长艺术创作，实际测试是找到最适合项目的关键一步。 （ 文章来源：Tencent Cloud ）
1 年前
我们在开发网站的时候，往往有想克隆别人网站的想法。那么在技术上怎么才能实现呢？ ⚠️ 重要提示 确认目标网站的版权和合法性：如果你没有目标网站的授权，直接克隆并使用可能会侵犯版权或违反法律。 如果只是想模仿其功能或界面，建议自行开发类似的网站，而不是直接复制。 如果你拥有授权，可以使用以下方法进行克隆。 ? 方法 1：使用 HTTrack 下载整个网站 HTTrack 是一个网站克隆工具，可用于离线浏览： 下载安装 HTTrack（Windows/macOS/Linux 都支持）。 创建新项目 并输入目标网站 URL地址。 启动克隆，HTTrack 会下载 HTML、CSS、JS、图片等资源。 本地查看和编辑，然后上传到自己的服务器。 缺点： 只能克隆静态页面（HTML、CSS、JS），无法克隆后端功能（如 API、数据库、登录系统等）。 如果目标网站有反爬虫策略，可能无法完整下载。 ? 方法 2：手动分析 & 重新开发 如果你想复制网站的功能，而不仅仅是外观，建议进行以下操作： 1. 分析网站前端 使用 Chrome 开发者工具（F12） 查看 HTML 结构、CSS 样式和 JavaScript 逻辑。 使用 Postman 或浏览器 Network 面板 分析 API 接口调用方式（如果适用）。 复制或编写类似的 HTML/CSS/JS 代码，实现前端界面。 2. 分析网站后端 如果网站有 API 接口、数据库等后端功能，需要： 观察 API 调用（GET/POST 请求）以了解数据交互方式。 搭建类似的后端（Node.js、Python、PHP、Go 等），并使用数据库（MySQL、MongoDB 等）。 如果网站使用的是 OpenAI API，你可以在 申请 API Key，然后在你的项目中集成 ChatGPT 或 DALL·E 相关功能。 3. 部署你的网站 本地开发：使用 HTML + CSS + JavaScript + 后端框架（如 Flask、Express、Django）。 云端部署：选择服务器（AWS、阿里云、Vultr、腾讯云等）并部署网站。 ? 方法 3：使用 Web Scraping（仅用于数据获取） 如果你只想获取网页上的文本数据，可以使用 Python + BeautifulSoup / Selenium 进行爬取： import requests from bs4 import BeautifulSoup url = "http://openai.cha-tai.cn/" response = requests.get(url) soup = BeautifulSoup(response.text, 'html.parser') # 提取页面文本 text = soup.get_text() print(text) 注意： 如果网站有反爬虫机制，可能需要使用 Selenium 或 Scrapy 进行爬取。 只能获取静态数据，无法克隆网站的功能。 ? 结论 如果你只是想获取网站的内容，HTTrack 或 Web Scraping 可能够用。 但如果你想克隆网站的功能，建议分析前端和后端结构，并自行开发。
1 年前
比GraphRAG更懂“思考”，微软又开源PIKE-RAG：主打复杂私域知识理解和推理 继GraphRAG之后，微软又发布PIKE-RAG，主打在复杂企业场景中私域知识提取、推理和应用能力，PIKE-RAG 已在工业制造、采矿、制药等领域进行了测试，显著提升了问答准确率。报告、代码、demo均已开源。
2 年前
以下是一些关于 RAG（Retrieval-Augmented Generation，检索增强生成）企业落地的成功案例： Salesforce Einstein Salesforce 利用 RAG 技术打造了 Einstein 智能助手。 功能与应用：Einstein 可以从大量的客户数据、销售记录、市场趋势等信息中进行检索，并结合生成式回答来为销售团队提供个性化的建议和洞察。例如，当销售代表与客户沟通时，Einstein 能够快速检索相关客户信息和历史交易记录，同时生成针对当前情况的最佳销售策略建议，如推荐合适的产品、提供优惠方案等。 成果与效益：通过使用 Einstein，Salesforce 的客户企业显著提高了销售效率和客户满意度。销售团队能够更快速地响应客户需求，准确把握销售机会，从而增加了销售额和市场份额。同时，客户也受益于更加个性化和高效的服务体验。 Cisco with RAG for Customer Support Cisco 在客户支持领域应用了 RAG 技术。 功能与应用：当客户遇到技术问题时，Cisco 的支持系统可以从庞大的知识库中检索相关的解决方案和技术文档，并利用生成式模型为客户提供清晰、易懂的解答。例如，如果客户报告网络故障，系统会检索类似问题的历史解决方案，并根据当前情况生成具体的故障排除步骤和建议。此外，支持团队也可以利用该系统快速获取相关知识，提高解决问题的速度和准确性。 成果与效益：这大大缩短了客户等待解决问题的时间，提高了客户满意度。同时，Cisco 也降低了支持成本，因为系统可以自动处理许多常见问题，减少了人工干预的需求。 金融行业中的应用案例 某大型金融机构利用 RAG 技术提升风险管理和投资决策。 功能与应用：该机构将大量的金融市场数据、经济指标、行业研究报告等信息整合到 RAG 系统中。在进行风险管理时，系统可以检索历史市场波动数据和风险事件，并结合生成式分析提供当前市场风险的评估和预警。在投资决策方面，系统能够根据用户的投资目标和风险偏好，从海量数据中检索合适的投资组合建议，并生成详细的投资分析报告。 成果与效益：帮助金融机构更准确地评估风险，做出更明智的投资决策。提高了决策的效率和准确性，降低了投资风险，为机构带来了显著的经济效益。 这些成功案例展示了 RAG 技术在不同行业的广泛应用和巨大潜力，为其他企业考虑落地 RAG 提供了宝贵的参考经验。
2 年前
当将 RAG 企业落地时，以下是一些需要注意的事项： 数据质量与管理： 确保数据的准确性、完整性和一致性。对用于检索的知识库进行严格筛选和清理，去除错误、过时或不相关的信息，以免影响生成结果的质量。 建立有效的数据更新机制，以保证知识库中的信息能够及时反映最新的知识和业务动态。例如，定期更新文档、数据库记录等。 对数据进行分类和标记，便于在检索时能够准确地定位到相关内容。这可能涉及到制定合适的分类体系和标签规则。 查询处理与优化： 针对不规范的查询和短查询，采用合适的处理方法。例如，通过意图分析确定用户意图，缩小召回范围；进行关键词提取，以便根据关键词进行检索；或者主动向用户提问以获取更多信息，从而使查询更加明确。 优化查询的性能和效率，避免出现响应时间过长等问题。可以通过选择合适的索引技术、优化检索算法等方式来提高查询速度。 集成结构化数据：如果企业中存在结构化数据（如关系数据库、Excel 文件等），需要考虑如何将其有效地整合到 RAG 流程中。这可能需要开发相应的数据接口或转换工具，以确保结构化数据能够与非结构化数据一起被检索和利用，为生成更全面和准确的回答提供支持。 模型选择与调优： 根据企业的具体需求和应用场景，选择合适的 RAG 模型架构和相关技术。不同的开源框架或商业解决方案在功能、性能、可扩展性等方面可能存在差异，需要进行充分的评估和比较。 对所选的模型进行调优，包括调整参数、优化训练过程等，以提高模型在企业数据上的表现。例如，可以使用特定领域的数据集进行进一步的微调，使模型更好地适应企业的业务知识和语言特点。 结果评估与反馈： 建立评估指标体系，对 RAG 生成的结果进行客观的评估。这可以包括准确性、相关性、可读性等方面的指标，通过与人工标注的结果进行对比或进行用户满意度调查等方式来衡量生成结果的质量。 根据评估结果，及时收集反馈信息，以便对模型和系统进行进一步的改进和优化。例如，如果发现某些类型的问题经常出现错误回答，可以针对性地调整数据或模型。 安全与隐私保护： 确保企业数据的安全，采取措施防止数据泄露、未经授权的访问等问题。这可能涉及到数据加密、访问控制、安全审计等方面的技术和管理措施。 如果处理的是包含个人隐私信息的数据，必须严格遵守相关的隐私法规和政策，对用户隐私进行保护。例如，在数据收集、存储和使用过程中，明确告知用户并获得其同意，对敏感信息进行脱敏处理等。 可扩展性与兼容性： 考虑企业未来的发展和业务扩展需求，选择具有良好可扩展性的 RAG 解决方案。这包括能够支持更大规模的数据量、更多的用户访问以及更复杂的应用场景等。 确保 RAG 系统与企业现有的技术架构和软件系统具有良好的兼容性，能够方便地进行集成和对接。例如，与企业的业务系统、数据库、应用程序等进行无缝连接，以实现数据的共享和交互。 用户体验与界面设计： 设计友好、直观的用户界面，使用户能够方便地输入查询并理解生成的回答。提供清晰的操作指引和反馈信息，降低用户的使用门槛和学习成本。 优化生成结果的呈现方式，使其易于阅读和理解。例如，对长篇幅的回答进行分段、突出关键信息、提供相关的参考资料或链接等。 成本控制与效益分析： 评估 RAG 项目的成本，包括技术采购、数据处理、模型训练、系统维护等方面的费用，确保在企业的预算范围内。 分析 RAG 系统为企业带来的效益，如提高工作效率、改善客户服务、创造新的业务机会等，以证明项目的投资价值。通过持续的效益分析，不断优化 RAG 系统的应用策略，以实现最大的收益。 法律合规性：了解并遵守相关的法律法规，特别是在涉及知识产权、内容创作、数据使用等方面。确保 RAG 生成的内容不侵犯他人的版权、商标权等合法权益，避免可能的法律风险。 总之，RAG 企业落地需要综合考虑技术、数据、业务、用户等多个方面的因素，通过精心的规划、实施和不断的优化，才能实现其在企业中的有效应用和价值最大化。在实施过程中，建议与专业的技术团队、法律顾问等进行合作，以确保各项工作的顺利进行。
2 年前
RAG 技术在不同行业的广泛应用和巨大潜力，企业利用RAG技术激活企业内如数据，让企业再次焕发生命力！
