十年前我刚入行那会儿，为了拿一个销售报表，得先在群里吼一声，找数据开发排期，等半天拿到 CSV，再用 Excel 透视表折腾半小时。那时候我就想，要是能直接问数据库要数据就好了。后来有了 BI 工具，确实方便了些，但门槛还是高，业务方不懂 SQL，只能依赖我们写查询。现在 AI 火了，大家都说自然语言问数能解决这个问题，但真正落地的没几个，要么太贵，要么太慢。
最近我把这个老念头重新捡起来，用 SQLite 加 DuckDB 做了一个可视化的 AI 问数平台，完全开源。你没听错，不是那些动辄显存爆掉的大模型方案，而是用最朴实的本地数据库组合。今天不聊虚的，就聊聊为什么选这两个家伙，以及我在中间踩过的坑。这不仅仅是个工具，更是我对当下 AI 应用落地的一种思考，希望对你有点启发。
很多人一听到做数据平台，第一反应就是 MySQL 或者 PostgreSQL，再不济也是 ClickHouse。这没错，它们是工业界的标配，稳如泰山。但咱们做个人项目或者中小团队内部工具，有时候杀鸡不用牛刀。SQLite 就像你家里那个用了十年的老工具箱，啥都能装，不用配置服务器，一个文件就走，特别适合存元数据和配置信息。它不需要你操心维护，就像那个永远在后台默默支持你的老同事。
而 DuckDB 则是近年来的新贵，专门用来做 analytical processing。如果说 SQLite 是仓库管理员，那 DuckDB 就是高速分拣机。它能在内存里飞快地处理列式数据，特别适合 AI 生成 SQL 后的查询执行。当年我在一个大厂项目里，因为选错了数据库引擎，查询慢得让人想砸键盘。这次我学乖了，让 SQLite 管状态，DuckDB 管计算，各司其职，性能反而比单用一个重型数据库要好得多。
再说 AI 这部分，现在的趋势是把大模型当翻译官用。你把人话发给它，它翻译成 SQL 发给数据库。听起来简单，做起来全是坑。最大的问题就是幻觉，模型有时候会编造不存在的字段。我刚开始直接把表结构丢给模型，结果它瞎写 join 条件，查出来的数据能对才怪。后来我加了个中间层，先用向量检索找回相关的表结构描述，再让模型生成，准确率才上来。这就像你问路，得先告诉对方你在哪个区，它才能指对方向。
还有个容易被忽视的点，是数据隐私。很多公司不敢用 AI 问数，就是怕数据传到公有云模型上。我这个方案主打本地化，模型可以部署在内网，数据不出域。当年我们做个金融项目，因为数据合规问题，方案改了三版。现在技术成熟了，本地跑个小模型配合本地数据库，既能享受 AI 的便利，又能守住安全底线。这对于很多对数据敏感的团队来说，可能是个更可行的切入点。
当然，这方案也不是万能的。如果数据量到了亿级，DuckDB 单机内存可能扛不住，那时候还是得回归分布式集群。技术选型从来没有最好的，只有最合适的。我见过太多人盲目追求新技术，最后项目死在维护成本上。这个平台适合什么场景？适合内部数据分析、个人知识库查询、中小企业的报表需求。它不是要取代现有的数仓，而是给它们加个友好的对话界面，让数据真正流动起来。
最后说说开源这事儿。代码我已经整理好放在仓库里了，没什么复杂的依赖，docker 一键就能跑。我做这个不是为了炫技，而是希望更多人能低成本体验 AI 落地的乐趣。以前我们总觉得高大上的系统得几百人团队搞几年，现在几个人几周就能做出能用的东西。技术的本质是服务于人，而不是让人服务于技术。如果你也对数据可视化感兴趣，或者想试试 AI 结合数据库的玩法，欢迎拿去玩玩，提提意见。
