去年有组数据挺有意思：用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的代码删了。」
热门跟贴