原本以为现在头部 AI 模型的幻觉已经很低了，而且觉得我挺能辨别 AI 幻觉的，结果今天还是被摆了一道

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

用 Django ORM 写了个函数查询 Postgres 数据库，发现 ORM 的速度比原生 SQL 语句慢了好几倍，于是去问 Gemini 2.5 。

Gemini 让我打印出生成的 SQL 语句看看是怎么一回事，我一看，ORM 查询条件是大小写不敏感的，使用了icontains算符；但是 Django 在把查询条件翻译成 SQL 语句的时候没用上 Postgres 特有的不区分大小写的ILIKE算符，而是将式子两边都转换成了大写，用了UPPER() LIKE UPPER()。这下知道原因了，这种情况下字段的索引根本没用上。

那就改嘛。然后 Gemini 信誓旦旦地告诉我，这是非常不同寻常的，Django ORM 肯定能自动将 icontains 翻译成ILIKE。我觉得也很有道理，Django 这么老牌的框架，Postgres 也不是什么冷门数据库，怎么会处理不好适配呢，肯定是我自己的问题。

然后我就照着 Gemini 给的方案一步一步调试，是不是你的 Django 配置有问题？是不是 Django / psycopg / Postgres 版本哪里冲突了？做个最小化测试试试？每一步都没有问题，我跟 Gemini 都感到非常困惑。

两个小时之后我才意识到有哪里不太对劲，于是新开了一个对话让他联网搜一下有没有人遇到过类似情况。然后他哐哐搜出来好几篇网页，网页里的人类全都明确地指出 Django 会把icontains转换成UPPER()。但是就算是在包含了这些信息的新对话里，Gemini 还是嘴硬地声称：

标准行为是 ILIKE：多个来源（包括 Django 官方讨论、Stack Overflow 、博客文章）都明确指出，对于 PostgreSQL ，Django 的 icontains 应该被翻译成 ILIKE 。这是 Django 利用 PostgreSQL 对大小写不敏感的 LIKE 查询的原生支持的方式。

最后我只能去翻了翻 Django 的源码，发现源码里确确实实是将icontains翻译成了UPPER() LIKE UPPER()，没有用上ILIKE，原来整个大前提都是 AI 的幻觉。又问了问几个头部模型，每一个都热心地指点我应该如何排查问题，要怎样怎样解决，没有一个指出来这确实就是 Django 应有的行为。反思了一下，我现在写代码似乎有点太过于依赖 AI 了……

django

orm

SQL

11 条回复 • 2025-04-16 14:21:56 +08:00

yiqiao

8 天前

AI 的数据源不就是从互联网上拉下来的吗，这种情况你只能缩小范围，甩一个文档或者源码地址，让它阅读后再问。不过有时候他依然回答的结果还是一样的。

billccn

8 天前

你可以据此到 Django 那开一个 ticket：连 AI 都觉得你们应该用 ilike 。

不过我得说，除非你这个索引是专门的 trigram 等搜索优化类型的，普通的字符串索引碰到 ILIKE 还是要从头到尾扫描的，最多数据量比扫全表少，但是不再是索引应该有的 O(log(n))。你还不如专门建一个 UPPER()索引。