上一篇使用 Whisper 把语音转换成文字，再交给 Qwen3 回答。这个过程可以实现语音输入，但 Qwen3 实际接收到的仍然只有文字。 如果还希望程序理解图片，就需要增加真正的多模态模型。本文在 M1 Max 上部署 mlx-comm

上一篇完成了一个可以保存多轮历史的聊天机器人，但它只能在终端中运行。普通用户更习惯在网页里输入消息，也希望直接使用麦克风说话。 本文为聊天机器人增加 Gradio 页面，并使用 MLX Whisper 在 Apple Silicon 上完成

前文已经介绍了本地模型、OpenAI 兼容接口、消息、提示词模板和输出解析器，但每个示例基本都只完成一次调用。 真正的聊天机器人还要解决一个问题：用户说完第一句话后，模型能不能在第二轮继续理解前面的内容？ 例如： 用户：我叫小明。 助手：你

前文已经介绍了消息和提示词模板。前面的示例向模型发送问题后，得到的主要还是一段自然语言。 自然语言适合人阅读，但程序更希望得到稳定的数据。例如，程序需要的天气信息可能是： { "city": "北京", "conditio

上一篇介绍了 LangChain 中的消息。我们已经知道，聊天模型接收的通常不是一段孤立文字，而是由 SystemMessage、HumanMessage、AIMessage 等对象组成的消息列表。 接下来会遇到另一个问题：消息结构可以固定

前两篇已经完成了本地 Qwen3 部署，并分别使用 OpenAI Python SDK 和 LangChain 调用了这个模型。 调用 ChatOpenAI 时，既可以直接传入一个字符串，也可以传入一个消息列表。字符串适合一次独立的问题；当

上一篇已经使用 MLX-LM 直接加载本地 Qwen3-14B-AWQ-4bit-MLX，完成中文生成测试，并把模型启动成只监听 127.0.0.1:18080 的本地 HTTP 服务。 直接加载模型适合验证模型文件和推理环境，但业务代码会

在开始写 LangChain 代码之前，先要准备一个可以稳定调用的大模型。 如果模型本身还不能正常加载，后面遇到问题时，就很难判断究竟是 LangChain 代码写错了，还是模型、运行环境、网络接口出了问题。因此，本系列先从最底层开始：把模

1. 为什么有了大模型还需要应用框架1.1 大模型不是完整应用Qwen、DeepSeek、GPT、Claude 这类大模型，主要负责理解输入和生成内容。 如果只是写一个简单问答程序，直接调用模型接口就可以： 用户问题 -> 模型 -> 模型

前面 14 篇已经把 Hudi 的概念、写入、索引、Spark、Flink、CDC、调优和底层原理基本串起来了。这一篇作为当前 Hudi 学习笔记主线的收尾，回到一个很现实的问题：Hudi 表已经写在 HDFS 上了，Hive 怎么查？ H

前面已经从表类型、索引、Spark 集成、Flink 集成、CDC、调优和高级能力几个角度把 Hudi 跑了一遍。到这篇，我想把视角往下一层放：同样是写入一条订单更新，Hudi 内部到底怎样判断新旧、怎样找到文件、怎样把 Log File

前面几篇已经把 Flink 写 Hudi 的基础链路、参数调优、CDC 入湖都跑过了。到这里，Flink Hudi 已经不只是“建表、写入、查询”这么简单了。继续往生产场景走，会遇到更多高级能力：Changelog、Append 模式、Cl