不少朋友可能都面临一个痛点：满怀期待地把资料“投喂”进知识库，以为大模型能把所有内容完整“消化吸收”，结果一测试发现问答效果不尽如人意。其实这不一定是方法不对，而是RAG本身有它的软肋。
先要明白一点：RAG不是银弹，不是全能的，它有自身局限，并不适合所有场景。RAG的原理网上资料很多，这里不细说。下面这张图直观展示了它的工作过程。
RAG的几个核心局限
1. 文件分片导致上下文丢失
分片本身不是问题，但把原本连贯的内容割裂开，后期检索到的信息就容易缺失关键上下文。
2. 检索不精确
RAG用向量比对（从数学维度找语义相近的内容），有时匹配到的并不一定是真正需要的信息。
3. 没有全局概念
知识库的文件全是分片存储，每次回答只检索局部片段，很难回答像“知识库中一共有多少位老师”或“一季度有多少个订单”这类统计型全局问题。
针对第一个问题（分片导致上下文丢失），在之前的分享中已经给出了一个解决方案：大力出奇迹 —— 使用超长上下文模型，把相关甚至不相关的内容全检索进来，扔给大模型自己去判断。这要求模型有超强的“大海捞针”能力。感兴趣的朋友可以看看：
超长上下文开源模型minimax-01，支持400万tokens，效果显著提升。搭配Dify v1.1.0接入后，知识库效果直接起飞。
剩下的两个问题，可以搭配传统数据库来解决。其实一个月前就有朋友提过这个方案，但当时觉得操作太繁琐，不够成熟，就一直没分享。直到最近MCP大火，让AI大模型接入数据库的门槛降了一大截。再加上平时最常用的字节旗下AI IDE神器Trae，终于支持MCP了！
国内版Trae下载：https://www.trae.com.cn/
海外版Trae下载（需科学上网）：https://www.trae.ai/
Trae直接内置了数据库的MCP Server，这意味着我们可以通过MCP把数据库一键接入大模型。本期以PostgreSQL这个简单轻量的关系型数据库为例，带大家接入（它应该能满足大部分使用场景）。
声明：数据库方案更适合表格类型的数据。文本类建议参考“大力出奇迹”方案。
使用Trae的MCP能力需要先在本地安装Python环境和Node环境（网上资料很多，也可以问AI）。好了，下面开始喂饭。
一、安装PostgreSQL
PostgreSQL官网下载：https://www.postgresql.org/download/
选择合适平台，跟着流程点点点就行。然后安装一个图形化界面方便操作数据库，推荐免费的DBea ver。
DBea ver下载：https://dbea ver.io/download/
打开DBea ver，点击右上角小“+”号，选中PostgreSQL。其他默认配置，只需填上安装PostgreSQL时设置的密码，点击完成。添加好本地PostgreSQL后，左侧会出现小图标，双击连接数据库，按提示安装相关驱动。驱动安装成功后，数据库大象图标上会出现一个小勾。
二、在Trae中配置PostgreSQL MCP
打开Trae，按下图方式操作。如果第一次没有MCP，会提示需要添加MCP，进入MCP市场，添加PostgreSQL。
特别注意：上面复制的PostgreSQL URL不能直接粘贴，需要参考格式调整：
postgresql://postgres:密码@127.0.0.1:5432/postgres
其他部分不变，把密码改成自己的。
点击确认后，Mac用户如果遇到路径权限报错，可以在终端运行：
sudo chown -R $(whoami) ~/.npm
PS：其他任何报错都可以丢给Trae，让AI帮你解决。
直到PostgreSQL MCP变为“可用”状态，就配置好了。
为安全起见，MCP只提供查询功能，无法进行增、删、改。
三、测试PostgreSQL MCP效果
接下来需要把测试数据导入PostgreSQL。我准备了一个Excel表格，是之前在某宝爬取的135条内存条商品信息。
直接用几天前发布的“扣子空间”，让这个表格转为可导入PostgreSQL的SQL文件。
提示词是这样写的：
我想把这个Excel导入PostgreSQL（表需要新建），根据Excel内容生成导入所需的SQL文件，记得把列名翻译成英文，考虑字段字符串长度是否足够等因素，生成后供我下载。
说实话，扣子空间挺好用的，半分钟不到就搞定了。如果换成以前，得写代码或用Excel表达式吭哧吭哧搞半天。
把生成的SQL文件下载下来，按步骤导入PostgreSQL数据库，并可以按图查看导入成功的数据。
然后开始测试。注意：由于大模型不知道表格结构和信息，需要把表格结构连同问题一起发过去（如果是智能体，可以把表格结构放到系统提示词中）。表格结构在之前生成的SQL文件中可以找到。
查询结果完全正确。这个方案是由大模型写SQL语句来查询，查询精度是有保证的。实测Claude 3.7比新版DeepSeek更好用，至少SQL语句写得更符合要求。
这个方案还可以结合RAG一起用：比如做一个工作流，在最前面加一个大模型判断，用户问题如果是全局或统计性质，就走数据库；否则走RAG。这样结合起来，能极大提升整个知识库的检索精度。
写到这里，不禁想起当年刚做程序员的时候，有几个月每天写各种复杂的SQL，从生疏到炉火纯青。现在看来好像没多大用处了，因为AI完全可以秒出。技术发展得真快，而我们好像只能不断紧跟步伐，才不至于被淘汰。