开源RAG平台chatVia.ai：全栈检索管线与自主部署

一位开发者耗时一年打造的RAG平台chatVia.ai正式开源，它试图回答一个直白的问题：为什么每个团队都要为“能读自家文档的AI代理”支付月费？答案是把整套检索栈塞进Postgres，让数据留在自己的服务器上，并且提供一行安装命令与自动更新。据Reddit原帖介绍，平台支持无限代理与无限回复，无需单独运行向量数据库。

从摄取到生成：一条可调的RAG流水线

chatVia.ai的RAG管线按阶段组织，每个环节都暴露了可调参数，而非黑盒封装。

摄取与分块：内容感知是起点

文件、网站、纯文本、问答对和YouTube转录文本都会被转成文档。Web爬取遵守路径规则，重新爬取时只对变更部分重新嵌入，避免全量重算。分块策略按内容类型分流：Markdown按标题切分，散文按句子切分，其余按固定窗口加重叠。块大小与重叠比例可按代理单独调整，这对不同文档结构（如API文档与博客文章）的检索效果差异很大。

上下文增强与嵌入：让“第二个选项”也能被检索

嵌入前，每个块会由LLM生成一段简短的上下文，说明它在原文中的位置。这样即使块内只写着“第二个选项”，单独检索时也能命中正确语义。嵌入模型可选OpenAI、Mistral、Gemini、Cohere、Jina、Voyage、Qwen3或OpenRouter，存储为halfvec并建立HNSW索引，据作者称索引体积减半而召回率不变。

halfvec 是 pgvector 扩展提供的半精度（16 位浮点）向量类型，相比默认的 float32 向量每个维度只占 2 字节，存储与内存开销大约减半。HNSW（Hierarchical Navigable Small World）是一种基于多层图的近似最近邻索引，查询时从稀疏的顶层图逐层贪心下降到稠密底层，以对数级复杂度找到近邻，代价是索引构建较慢且占用额外内存。HNSW 的核心可调参数包括控制图连接数的 M 和构建时搜索宽度的 ef_construction，查询时还有 ef_search 影响召回率与延迟的权衡。半精度向量确实能显著压缩索引体积，但对召回率的影响取决于模型与数据分布，通常需要实测验证而非普适保证。

混合检索与融合：向量加BM25

每次查询并行跑两个检索器：基于pgvector的稠密向量相似度，以及Postgres内的稀疏BM25关键词搜索。语义匹配与精确词匹配都会进入候选集，再用Reciprocal Rank Fusion合并两份排名列表。RRF的好处是不需要手工调分数权重，在两个列表中都靠前的块自然浮到顶部。

BM25 是信息检索领域的经典稀疏检索算法，它基于词频（TF）与逆文档频率（IDF）对文档打分，并对长文档做长度归一化，偏好包含查询关键词的文档。与稠密向量检索不同，BM25 依赖精确的词项匹配，因此对专有名词、型号、代码标识符等罕见词特别敏感，而这些恰恰是向量模型容易模糊化的场景。RRF（Reciprocal Rank Fusion）是一种无需训练、无需调参的排名融合方法：对每个文档在各检索列表中的名次取倒数后求和，名次越靠前贡献越大。它的优势在于只使用名次而不使用原始分数，因此不必担心向量相似度与 BM25 分数量纲不一致的问题，实现简单且鲁棒。

重排与过滤：挡住“你好”引发的噪声

融合后的候选由交叉编码器重排器（Cohere、Jina、Voyage等）针对实际问题重新打分，只保留顶部段落。相似度门控会丢弃弱匹配，避免一句问候拖入无关块。查询改写环节则处理“那第二个呢？”这类追问——先用对话上下文重写查询再检索，查询过于模糊时代理还能主动请求澄清。

交叉编码器（cross-encoder）与常见的双塔嵌入模型在结构上有本质区别。双塔模型把查询和文档分别编码成向量再算相似度，文档向量可以离线预计算，适合大规模召回；交叉编码器则把查询与文档拼接后一起送入 Transformer，让注意力机制在两者之间充分交互，因此打分更精准，但无法预计算文档表示，只能对少量候选逐一推理。这正是它被放在检索管线末端、只对融合后的顶部段落重排的原因：用可接受的延迟换取排序质量。实践中常见做法是先用廉价检索召回几十到上百条，再用交叉编码器精排出前几条交给生成模型。

引用与护栏：可核查与可控

每个答案都链接回来源块，用户可以核对原文而非盲信模型。护栏在内容进入模型前拦截提示注入、跑题问题、有毒内容和个人数据。检索评估则允许一次性写好测试问题，由LLM-as-a-judge给每个答案打分，这样在调整分块、嵌入或重排器时，能先知道检索是变好还是变坏，再决定是否上线。

LLM-as-a-judge 是当前评估生成式系统的主流范式：让一个能力较强的模型按给定评分标准（如相关性、忠实度、完整性）对系统输出打分，替代昂贵且缓慢的人工标注。在 RAG 场景中，它能批量评估“答案是否被检索到的原文支撑”，从而在改动分块大小、嵌入模型或重排器后快速对比检索质量。其局限也需注意：评判模型可能存在位置偏好、长度偏好以及与自身训练分布相关的偏见，评分标准的设计质量直接决定结论可靠性。因此实践中常配合少量人工标注做校准，并对关键指标做多次采样以降低方差。

生成模型与外围能力

生成端不绑定单一供应商，开放权重模型如Qwen3，或OpenRouter、Mistral、Groq、Scaleway上的模型都可随时切换。管线之外，平台提供聊天挂件、托管聊天页、⌘K命令栏，并接入Slack、WhatsApp、Telegram、Teams、Instagram和Messenger。工具与MCP支持审批和日志记录，团队、角色、审计日志、双因素验证和通行密钥（passkeys）也在开源范围内。

开源边界与商业化：Pro密钥解锁什么

作者采用了一种常见的开源商业模式：核心RAG能力免费，Pro密钥解锁REST API、实时人工接管、聊天内表单与线索收集、语音对话、图像/视频/音频生成、更深层分析、自定义域名和更多工作区。作者直言，一个人维护的项目需要自己养活自己。对自托管团队而言，这意味着可以先零成本验证检索质量，再按需为外围功能付费。

为什么“检索栈住进Postgres”值得关注

把向量检索、BM25、RRF融合都放在Postgres内，减少了运维组件数量。对中小团队来说，少一个专用向量数据库就少一套备份、监控和权限体系。halfvec加HNSW的取舍（索引减半、召回不变）在存储成本敏感的场景下有实际意义。不过，这也把性能上限与Postgres的调优绑定在一起，大规模并发下的表现需要实际压测验证。作者在帖尾的邀请很直接：如果你试过，告诉我哪里坏了。

适合谁

有自有文档、对数据出域敏感、又不想为每个代理付订阅费的团队，是这个项目最直接的目标用户。已经踩过分块、召回和重排坑的RAG开发者，也能从它的可调参数和检索评估设计里找到参考。