Search: #RAG

面条的草稿箱

1. 10:47 · 2025年12月27日 · 周六

   Ref：给你的 AI Agent 一份“刚刚好”的文档上下文
   
   做 AI 编程助手最怕两件事：胡编和上下文膨胀。Ref 主打的就是把问题变简单——让你的 Agent 能随用随查公共/私有技术文档，只拿“够用且准确”的信息。
   
   它怎么做？
   Ref 通过 MCP（Model Context Protocol）把文档上下文接到你的 AI 工具里：既有持续更新的公共文档索引，也支持把你的私有资料（如 GitHub 仓库、PDF）纳入检索。
   
   给 Agent 的两个核心能力：
   
   • search_documentation：面向技术文档的精确搜索，能定位到具体章节，支持公有与私有文档集。
   • read_url：读取任意网页或 GitHub 文件内容（可含私有内容），适合顺藤摸瓜跟进链接。
   
   为什么不是“东拼西凑工具链”？
   你当然可以分别用：代码片段、搜索、爬取、私有代码检索、PDF 检索等工具组合；Ref 的定位是把这些需求尽量合并成一个更统一的入口，减少集成成本与上下文噪音。
   
   安全与企业能力（官方强调点）：
   
   • SOC2 合规（并提供 Trust Center 与隐私安全说明）
   • 支持 SSO 与 MCP OAuth
   • 提供“主动提示注入防护”（对返回的上下文做注入扫描，仍在开发中）
   
   定价概览：
   
   • Free：200 credits（不刷新、不失效，官方估算约 10 周常规使用）
   • Basic：$9/月，1000 credits
   • Team：$9/月/席位，1000 credits/席位（团队共享私有文档索引与统一账单）
   • Enterprise：SSO、SOC2、优先支持、定制化等
   
   如果你在用 Claude/Cursor/Zed 等工具做工程开发，且经常需要“查最新文档 + 查公司内部资料”，这种“面向文档的上下文层”会比泛用搜索/爬虫更省 token，也更贴近代码场景。
   
   原链接：https://ref.tools/
   
   #MCP #开发者工具 #技术文档 #AI编程助手 #RAG

   ref.tools

   Ref - Context for your coding agent

   Give your agent the docs it needs to succeed. Exactly the tokens you need, no bloat.

2. 22:23 · 2025年12月24日 · 周三

   用 Payload CMS + Vercel AI SDK 搭建“可运营”的 AI 应用
   
   把 AI 做到生产可用，更多是架构问题：提示词不该写死在代码里，长任务要能可靠重试，Embedding 要能查询，输出要结构化可校验，更关键的是——要能看见系统到底“说了什么、做了什么”。
   
   这篇文章分享了 InnoPeak 在 FinSureTech 场景下的一套实践组合：用 Payload CMS 做“可视化、可配置的 AI 后端”，用 Vercel AI SDK 做“结构化生成与工具调用的运行层”，形成一条从配置、执行到观测的闭环。
   
   1) 用 Payload 管理 Prompt 与模型选择（不发版也能调）
   
   • 把系统/用户提示词做成模板（如 Handlebars），集中放在 Payload 的 globals 里
   • 模型 ID 用受控下拉选项管理，避免随意输入造成线上不可控
   • 非开发同事也能在后台安全修改提示词与模型策略，应用逻辑保持稳定
   
   2) 在后台“可视化”JSON Schema，提升结构化输出可靠性
   
   做结构化输出（JSON schema）时，最大的成本在测试与迭代。作者的做法是：
   
   • 在 Payload Admin 里直接渲染/展示 schema
   • 让开发者一键复制到测试对话或本地 LLM 环境验证
   
   这样能更快发现：字段缺失、类型不匹配、约束不被遵守等问题。
   
   3) 用 Payload Jobs Queue 跑长任务：重试、编排、定时都省了
   
   AI 工作流常有“慢”和“不稳定”：Embedding 生成、文档扫描、分段处理、失败重试……在 serverless 环境尤其麻烦。Payload 的 Jobs Queue 提供：
   
   • 任务与工作流编排
   • 重试与调度
   • 可用 Vercel CRON 或其他调度器触发
   
   把“队列基础设施”从应用里剥离出来，专注业务流程。
   
   4) Embedding 直接存进 Payload 的 Postgres（pgvector），再用 Drizzle 查
   
   Payload 本身不内建向量字段与索引，但可以用 schema hooks 扩展：
   
   • beforeSchemaInit 增加 vector 列，让生成的 Drizzle schema 也包含它（全类型化）
   • afterSchemaInit 创建 HNSW 向量索引、以及 GIN 文本索引（便于混合检索）
   
   随后即可在 API route / server action / task 里做相似度检索与排序，实现 RAG 的“数据库内闭环”。
   
   5) 记录 Token 与完整消息：成本可控、行为可追溯
   
   为了线上可观测性，作者在 Payload 里建了 TokenUsage 集合，保存：
   
   • 输入/输出/总 token（含缓存、推理 token 等）
   • 与模型交互的完整 messages（包含 tool calls）
   
   并通过 Vercel AI SDK 的 onFinish 钩子自动落库。好处是：复盘提示词与输出、定位异常、优化成本都有依据。
   
   结论很明确：AI 应用要“能跑、能改、能查、能追踪”，需要的不只是模型能力，更是把配置、数据与运行时纳入同一套可运营系统。
   
   原文链接：https://finly.ch/engineering-blog/916926-building-ai-native-applications-with-payload-cms-and-the-vercel-ai-sdk
   
   #PayloadCMS #VercelAISDK #AInative #RAG #可观测性

   finly.ch

   

   Finly - Building AI-Native Applications with Payload CMS and the Vercel AI SDK

   How we build AI-native FinSureTech applications at InnoPeak using Payload CMS and the Vercel AI SDK—breaking down real-world patterns for prompts, workflows, and AI-powered features that support modern financial advisors.