Anthropic把RAG做成乐高积木

去年有组数据挺有意思：用Claude API做RAG的开发者里，73%卡在第一步——不是模型调不好，是向量数据库的接口文档看得头疼。Anthropic和Supabase这次联手，把整套流程压成了三行配置。

这不是技术突破，是用户体验的降维打击。

传统RAG像装修毛坯房。你得选嵌入模型、搭向量库、写相似度算法、再缝进LLM上下文窗口——每一步都能踩坑。Anthropic的新方案把中间层全包了，开发者只负责两头：扔文档进去，拿答案出来。

Step 1：Supabase变成"智能文件柜"

打开Supabase的SQL编辑器，粘贴这段代码：

create extension if not exists vector;

create table documents (

id bigserial primary key,

content text not null,

metadata jsonb,

embedding vector(1536)

create index on documents using ivfflat (embedding vector_cosine_ops) with (lists = 100);

三行指令做完三件事：激活pgvector插件、建表、给1536维向量加索引。1536这个数字对应Anthropic自家的voyage-3嵌入模型，换别的模型得手动改维度——算是唯一的"自定义项"。

ivfflat索引的lists=100是个经验值。数据量小可以调低，百万级文档往上加。Supabase的文档没告诉你的是，这个参数直接影响查询速度和召回率的 trade-off，调错了会出现"明明有答案却搜不到"的灵异bug。

Step 2：分块策略比模型更重要

官方示例给了个512token分块+50token重叠的配置。这个数字背后是血泪教训：

chunkSize太大，单块塞进太多主题，相似度计算会"稀释"关键信息；太小又可能把一句话砍成两半，上下文断裂。512是Anthropic内部测过的甜点区，覆盖大多数技术文档和知识库场景。

代码实现用了最朴素的分词方式——按空格切单词。中文用户得自己换jieba或者别的分词器，这是示例没提的坑。

export function chunkText(text, chunkSize = 512, overlap = 50) {

const words = text.split(/\s+/);

const chunks = [];

for (let i = 0; i < words.length; i += chunkSize - overlap) {

const chunk = words.slice(i, i + chunkSize).join(' ');

if (chunk.trim()) chunks.push(chunk);

return chunks;

重叠区的50token是保险机制。假设一段关键信息正好落在边界，重叠能保证它被至少一个完整chunk捕获。代价是存储成本涨10%左右，但召回率提升通常值得。

Step 3：Claude API的"上下文注射"

检索端做完相似度搜索，拿到Top-K chunks，下一步是塞进Claude的prompt。Anthropic的 trick 在这里：不是简单拼接，而是用XML标签给每块打标记，让模型分清"知识来源"和"用户问题"。

系统prompt大概长这样：

Here are relevant documents:

{{#each chunks}}

{{content}}

{{/each}}

Answer based on these documents. If unsure, say you don't know.

XML标签是Claude的祖传手艺。GPT系列用markdown格式更顺手，但Claude对结构化标记的解析精度明显更高——这可能是Anthropic坚持这套方案的原因之一。

整个pipeline的延迟分布：嵌入查询~200ms，向量检索~100ms，Claude生成~2-5s。瓶颈永远在最后一环，所以前期检索的质量直接决定用户体验。召回错一块，模型会顺着错误上下文一本正经地胡说。

生产环境的隐藏成本

示例代码是玩具级别。真上生产得补几样东西：重试机制（Anthropic API偶发超时）、速率限制（embedding和生成是分开的配额）、缓存层（相同查询直接返结果）。

还有个没写在文档里的细节：voyage-3的嵌入质量和OpenAI的text-embedding-3-large打平，但价格只有1/5。这对高频写入场景是决定性优势——有些团队每月embedding账单能从四位数压到三位数。

Supabase的pgvector在单表百万行以下表现稳定，再往上建议分片或者换专用向量数据库。官方没给这条建议，但GitHub issue区里有人测过，500万行之后IVF索引的查询延迟会从100ms跳到800ms。

这套方案最聪明的地方是把"选择"变成了"默认"。不让你纠结用哪个向量库、哪种索引、怎么分块——全部给定，不满意再改。对想快速验证RAG价值的团队，这是最低摩擦的路径。

有个开发者在Hacker News的评论被顶到了前排：「我花了三周用LangChain搭RAG，bug一堆。用这套方案两天上线，现在只想把LangChain的代码删了。」