程序员视角:本地持久化RAG才是AI面试助手的最终形态

最近在GitHub上看到一个项目，叫 natively-cluely-ai-assistant，目前还处于 pending 状态，看介绍说是一个能持久化存储RAG的AI面试助手。

我盯着这个项目看了很久。

作为一个在工作中折腾过各种RAG方案的程序员，我想说，本地持久化RAG这个方向，可能是AI应用落地的下一个大趋势。

这篇文章不写具体代码，只聊我对这个方向的理解。为什么我看好它，为什么我认为它比云端方案更有前途，以及它当前面临的最大挑战是什么。

先说说什么是RAG

RAG，Retrieval-Augmented Generation，检索增强生成。

原理很简单，大语言模型在回答问题的时候，先从一个知识库里检索出和问题相关的内容，然后把检索到的内容连同问题一起发给模型，让模型基于这些内容生成答案。

你可以理解成，给AI配备了一个外部知识库，让它在回答问题的时候能「查资料」，而不是完全靠训练时学到的知识。

这样做最大的好处是什么，是知识的时效性和可控性。

你训练一个模型，成本可能几百万美元。但你想让这个模型知道今天刚发布的政策，或者你们公司的内部流程，对不起，模型不知道，你也没法快速更新。

RAG就是为了解决这个问题。你把最新的文档丢进知识库，AI马上就能用上。

现在很多公司在做的AI面试助手，底层基本都是这套架构。简历丢进去，JD丢进去，AI就能帮你分析匹配度，生成面试问题。

听起来很美好对不对。

但有一个核心问题，大多数RAG方案都没解决得好。

云端RAG的隐私之痛

现在的AI面试助手，大多是云端方案。

你把简历传上去，把职位描述传上去，让AI帮你分析。流程是顺畅的，体验也不错。

但你有没有想过，你的简历在云端经历了什么。

你的个人信息、工作经历、项目描述、离职原因，这些东西都传到了第三方服务器上。你根本不知道这些数据会被怎么存储、怎么使用、会不会被拿去训练模型。

很多人可能觉得无所谓。但如果你是一个正在找工作的程序员，简历上有你上家公司的项目细节，有你用过的技术栈，有你参与过的产品信息。这些东西泄露出去，后果可大可小。

更敏感的场景是内部知识库的问答。

很多公司想把内部的文档、代码库、运维手册做成AI问答系统。员工问AI问题，AI基于公司内部知识回答。这个场景下，你根本不可能把内部文档传到外部云端，这等于把公司最核心的资产送给第三方。

所以，云端RAG在很多场景下是有硬伤的。

不是不能用，是有些场景下根本不敢用。

本地RAG的核心价值

本地持久化RAG，就是把这个流程搬到本地。

你的数据留在你的机器上，不上云，不出境。AI在本地运行，知识库也在本地存储。隐私问题迎刃而解，数据主权完全在自己手里。

这就是 natively-cluely-ai-assistant 这个项目在做的事情。一个能持久化存储RAG的本地AI面试助手。

你把简历、本地资料库、职位描述全部存在本地，AI在本地做检索和生成。所有数据流转都在本地完成，不经过任何第三方服务器。

从技术上说，这不算什么突破。开源社区很早就有了本地的RAG方案，各种向量数据库也都有本地的部署方式。

但它代表了一个方向，这个方向我认为是对的。

本地模型能力在快速提升。Llama 3、Qwen、Mistral这些开源模型的性能，每年都在跨越式进步。本地跑模型的效果，越来越接近云端API调用。性能差距在缩小，成本优势在放大。
硬件成本在下降。现在一台16G内存的电脑，已经能跑70B参数的量化模型。顶级配置的工作站，跑个几百B的模型不成问题。对于个人用户和中小企业来说，本地部署的门槛已经低了很多。
隐私需求在爆发。随着AI渗透到各行各业，大家对数据隐私的敏感度在提高。程序员群体尤其明显，谁都不想自己的简历在云端裸奔。

这三个因素叠加，本地RAG的爆发期可能就在这两年。

持久化为什么重要

说到这里，有人可能会问，本地RAG之前不是也有吗，为什么还要强调持久化。

因为之前的很多本地RAG方案，有个致命的问题，数据不持久化。

什么意思。向量数据库跑在内存里，或者跑在临时文件里。重启一下，数据丢了。你得重新导入文档，重新做embedding，重新构建索引。一两次还好，每次重启都来一遍，谁受得了。

而且对于面试助手这种场景，数据的累积是很重要的。

你面了十家公司，有十个不同的简历版本和面试记录。你希望AI能记住你之前的面试表现，能根据你之前的回答调整后续的问题。如果你每次重启都要重建知识库，这些都没法实现。

持久化存储，本质上是让知识库变成了一个长期资产，而不是每次都要重建的临时文件。

只有实现持久化，RAG才能从「一次性工具」变成「长期助手」。

我理想中的AI面试助手

我自己在找工作那几年，踩过不少坑。

最痛苦的不是面试本身，是准备的过程。招聘信息分散在各个平台，简历要针对每个岗位调整，面试前要搜集大量资料，面试后没有复盘渠道。这些事情占用了大量精力，反而比面试本身还累。

如果有一个真正好用的AI面试助手，它应该能做到这些。

简历和JD的统一管理。你上传一份简历，上传多个JD，AI自动分析匹配度，给出优化建议。所有数据存在本地，不担心泄露。

模拟面试。基于JD生成针对性的面试问题，你口述回答，AI实时反馈，指出回答的亮点和不足。这比对着镜子练习强太多了。

面试复盘。每次面试结束，你把面试内容丢进去，AI帮你分析哪里答得好，哪里答得不好，下次怎么改进。这个知识库越积累越丰富，你每次面试都比上次更好。

长期记忆。你之前在哪些公司面试过，哪些问题回答得好，哪些是自己的薄弱项，AI都能记住。随着使用时间增长，AI对你的了解越来越深，提供的帮助越来越精准。

这四个场景，每个都需要持久化存储。用户数据、公司信息、面试记录、复盘笔记，这些都是需要长期积累的资产，不是用完就扔的临时文件。

所以本地持久化RAG，不是一个技术上的优化，是一个使用范式的改变。

从「用完即走」到「长期陪伴」。

挑战在哪里

看好这个方向，不代表它没有挑战。

本地RAG最大的问题，是性能和成本的平衡。

向量数据库的检索速度，本地模型的生成速度，这两个加在一起，对硬件要求很高。你想流畅地跑一个面试助手，可能需要一块不错的GPU。这对于很多用户来说，是一笔额外的投入。

其次是embedding模型的问题。本地跑embedding模型的效果和云端比，还有差距。如果embedding质量不高，检索到的内容不相关，RAG的效果就会大打折扣。

最后是用户体验。本地部署意味着用户要自己配置环境、自己维护系统。这对于技术背景不强的人来说，是一个不低的门槛。如何让本地RAG像云端应用一样开箱即用，是一个需要解决的问题。

这些都是工程上的挑战，随着时间推移和技术进步，会逐步解决。

但隐私问题、性能问题、成本问题，这三个核心矛盾，本地方案天然就能缓解。所以我认为这个方向是对的。

写在最后

程序员这个职业，有个特点，喜欢自己造轮子。

我之前也是这样，什么都想自己来，觉得自己写的代码最可控。但AI时代，这个思路可能要变一变了。

不是说不要自己动手，而是要想清楚，什么东西值得自己掌控，什么东西可以交给外部服务。

简历、个人项目、内部知识库，这些东西的隐私权重很高，值得自己掌控。

基础的模型能力、工具链，这些东西更新很快，自己造轮子反而容易被淘汰。

本地持久化RAG，本质上是把数据主权还给你。在这个AI能力越来越强大、但数据泄露风险也越来越高的时代，这件事的价值会越来越明显。

natively-cluely-ai-assistant 这个项目目前还在pending状态，我挺期待它正式发布的那一天。

也许它不会成为主流，但它代表的方向是对的。

数据归你，AI为我所用，而不是反过来。

理一——脑袋光光的琦玉老师 | 连续6年4点起床的程序员 | 注册营养师 | 14年健身老油条欢迎关注公众号「四点半的理一」