2025年3月

场景和问题

最近把主力数据库都全部切换成了PostgreSQL，并用于它开发了物料管理系统demo。为了测试大量数据对性能的影响，我给本地的库存表灌入了几十万种物料和80万行库存项。在关键词模糊搜索、多表联查等环节，我对其性能表现都很满意；但是当我在盘库凭证中添加抽盘项，而分页查询库存的页码又超大时，在前端拿到分页结果竟然要1.2s左右。毫无疑问，这个时间是有优化空间的。

查询库存的SQL语句类似于：

SELECT t."Id", t."Amount", t."Batch", t."CreatedAt", t."ExpiredAt", t."ExternalCode", t."IsLocked", t."Locker", t."MaterialCode", t."MaterialId", t."Note", t."ProducedAt", t.xmin, t."Scope", t."Slot", t."StockKind", t."WarehouseId", m0."Id", m0."Code", m0."MeasureUnitId", m0."ShortName", m0."Specification", m0."Status", m1."Id", m1."Abbrev", m1."Description", m1."Name", m2."Id", m2."Code", m2."Name", m2."PlantId"
      FROM (
          SELECT m."Id", m."Amount", m."Batch", m."CreatedAt", m."ExpiredAt", m."ExternalCode", m."IsLocked", m."Locker", m."MaterialCode", m."MaterialId", m."Note", m."ProducedAt", m.xmin, m."Scope", m."Slot", m."StockKind", m."WarehouseId"
          FROM mm_inventory AS m
          WHERE m."StockKind" IN (1, 2, 3) 
          ORDER BY m."Id"
          LIMIT 10 OFFSET 790000
      ) AS t
      INNER JOIN mm_material AS m0 ON t."MaterialId" = m0."Id"
      INNER JOIN mm_material_measureunit AS m1 ON m0."MeasureUnitId" = m1."Id"
      INNER JOIN mm_warehouse AS m2 ON t."WarehouseId" = m2."Id"
      ORDER BY t."Id"

上面这条查询语句稍显啰嗦，不过通过分析，很容易发现瓶颈出现在最内层的子查询上：

阅读剩余部分

目前LLM非常强大，但是如果只将它们用于聊天补全、生成图像这类生成式的场景，无异于自断双臂。近年来Agent的出现，必将会让AI渗透到日常生活中的方方面面。

微软的semantic kernel关于Agent的介绍是：

An AI agent is a software entity designed to perform tasks autonomously or semi-autonomously by recieving input, processing information, and taking actions to achieve specific goals.

尽管我加粗表示了我个人认为重要的几个关键词，但是不得不说，这个介绍写得让人摸不着头脑。相比之下，LangChain中对Agent的定义就非常简洁：

Agent is a class that uses an LLM to choose a sequence of actions to take.

总之，我心中的Agent，是指发挥LLM的长处，让LLM作为推理引擎，规划并执行外部动作。

本文简介

目前最火热的大模型当属OpenAI和DeepSeek，尤其是网上关于使用OpenAI构建Agent的子类非常多，但是在当前这个时间节点，我认为还有还有些不如意的地方：

  • 并不是每个中国人都能使用常规信道获得openai的key，也不是每个人都有国外信用卡来付费。
  • 至于DeepSeek，除了系统繁忙网络超时问题之外，DeepSeek著名的R1推理模型并不官方支持function calling(参见 https://github.com/deepseek-ai/DeepSeek-R1/issues/9#issuecomment-2604747754)，而截至今日，最新版的function calling尚不稳定。

注： DeepSeek 官方针对R1模型的函数调用给出了三种 walkaround：


- 使用脚本解析模型输出到结构化格式（比如：“JSON”格式）
- 设计提示词工程来指定模型产生特定格式的输出
- 自定义包装器，来模拟函数调用

所以，目前的尴尬就在于，我不想等：“高老师，我太想进步了”。

本文文章使用Ollama+QWen2.5来驱动。

  • Ollama的意义在于我们可以本地部署，避免依赖外部网络环境，这在涉密或者离线场合意义非凡。
  • QWen2.5的意义在于对中文支持非常好，不像是llama3.2那样，动不动就自动转换成英语，显得非常混乱。

阅读剩余部分