AI

oMLX是什么? omlx.ai（通常指 oMLX 项目）是一个专为 Apple Silicon（M1/M2/M3/M4 系列芯片）设计的本地大语言模型（LLM）推理服务器。它的核心目标是让 Mac 用户能够以极高的效率、极低的延迟在本地运行各种 AI 模型（如 Llama 3、Mistral、DeepSeek 等）。 简单来说，它是对 Apple 官方 MLX 框架的深度封装和功能扩展，提供了一个类似 OpenAI/Anthropic 接口的本地后端，并附带了美观的 macOS 菜单栏管理工具。 oMLX 速度提升的核心原理 oMLX 之所以能在 Mac 上跑出惊人的速度，主要归功于以下几个技术层面的深度优化： 1. 统一内存架构 (Unified Memory Architecture) 这是 Apple Silicon 的硬件优势，也是 MLX 框架的灵魂。 原理：在传统 PC 中，数据需要在 CPU 内存和 GPU 显存之间来回拷贝。而 oMLX 利用了 Mac 的统一内存，CPU 和 GPU 共享同一块物理内存。 提升：消除了昂贵的显存带宽瓶颈，模型数据加载到内存后，GPU 可以直接读取并处理，极大减少了延迟。 2. 双层 KV 缓存系统 (Two-Tier KV Cache) 这是 oMLX 最具创新性的优化点，解决了大上下文下的重复计算问题。 热缓存 (RAM)：正在进行的对话上下文保存在内存中，实现即时响应。 冷缓存 (SSD)：当内存满了或服务器重启时，oMLX 会将过往的 KV 缓存以 safetensors 格式持久化到 SSD。 提升：当你再次输入相似的 Prompt 或继续之前的长对话时，系统直接从磁盘恢复缓存，无需重新计算（Prefill）。这使得处理数万字上下文的“首字延迟”大幅缩短。 3. 连续批处理 (Continuous Batching) 通过集成 mlx-lm 的 BatchGenerator 技术，oMLX 能够同时处理多个并发请求。 ...

Function Calling（函数调用）是人工智能领域，特别是大语言模型（LLM）应用中的一项关键技术。它允许 AI 模型不仅生成文本，还能主动选择并执行外部定义的函数或工具，以解决超出其内部知识库的问题，或完成需要精确计算、实时数据查询等任务。 简单来说，就是让 AI 学会“调用代码”来干活，而不仅仅是“说话”。 1. 核心概念：AI 如何调用函数？ 在传统的 LLM 交互中，用户输入提示词（Prompt），模型直接生成文本回答。而在 Function Calling 模式下，流程发生了变化： 定义工具：开发者预先定义一组函数（Function Schema），描述这些函数的名称、参数类型、参数含义以及返回值。 模型决策：当用户提问时，模型会根据意图判断：是否需要调用某个函数？如果需要，它会自动生成一个包含函数名称和参数值的结构化请求（通常是 JSON 格式）。 执行与反馈：用户的后端服务器接收到这个请求，执行真实的函数逻辑，获取结果。 模型生成回答：系统将执行结果（如天气数据、搜索结果、数据库记录）传回给模型，模型结合原始问题和执行结果，生成最终的自然语言回答。 2. 为什么需要 Function Calling？ 大模型本身存在一些局限性，通过函数调用可以弥补： 时效性问题：LLM 的训练数据有截止时间，无法知道“现在的天气”或“今天的股价”。通过调用 API，模型可以获取实时数据。 精确计算与逻辑：LLM 在处理复杂数学运算或精确代码执行时容易出错（幻觉）。调用 Python 解释器或计算器函数可以得到 100% 准确的结果。 访问私有数据：企业的数据在内部数据库中，模型无法直接读取。通过调用内部 API，模型可以查询订单状态或用户信息。 控制输出格式：让模型生成结构化的 JSON 数据，而不是长篇大论的文本，便于程序后续处理。 3. 工作流程示例 假设你正在开发一个智能天气助手： 开发者定义函数： 函数名：get_current_weather 参数：location (string), unit (string: “celsius” or “fahrenheit”) 用户提问： “上海现在的气温是多少？用摄氏度表示。” 模型推理与调用： 模型识别到需要查询天气，于是输出如下结构（JSON）： { "name": "get_current_weather", "arguments": { "location": "上海", "unit": "celsius" } } 后端执行： 你的代码解析出 JSON，调用真实的天气 API，得到结果：{"temp": 24, "status": "sunny"}。 ...

一、什么是 RAG？ RAG 全称是 Retrieval-Augmented Generation（检索增强生成）。 为了理解它，我们需要先了解大语言模型（LLM）的两大痛点： 知识滞后性：大模型的训练数据截止于某个时间点，对于训练后发生的新闻、事件或企业内部数据，它一无所知。 “幻觉”问题：当面对未知领域的问题时，模型可能会自信地编造事实（Hallucination），导致输出内容看似通顺但内容错误。 RAG 的核心理念非常简单：不要让大模型去“背”所有知识，而是给它配一个“图书馆”。 当用户提问时，RAG 系统不会直接让大模型生成答案，而是先执行两步操作： 检索（Retrieval）：在外部知识库中搜索与问题最相关的信息。 生成（Generation）：将检索到的信息连同用户的问题一起交给大模型，让模型基于这些事实生成最终回答。 一句话总结：RAG = 大模型（生成能力） + 外部知识库（事实来源）。 二、RAG 是如何工作的？（工作流 + 代码示例） RAG 的工作流程通常包含以下四个关键步骤。下面我们通过一个具体的场景，用伪代码和逻辑图解来展示它是如何运行的。 🎯 场景设定 背景：一家科技公司的 AI 客服。 知识库（Vector DB）：包含《员工手册 2024 版》和《最新产品 Q3 发布说明书》。 用户提问：“我报销差旅费需要几个人审批？另外，Q3 发布的 AI 助手叫什么名字？” 问题难点： 审批人数在《员工手册》里，不在训练数据中。 产品名字是刚发布的，模型不知道。 🔧 步骤详解与代码逻辑 1. 数据准备与索引（Building the Library） 在系统上线前，我们需要将文档切片并转化为向量存入数据库。 # 伪代码：建立知识库 documents = [ "《员工手册》：差旅费报销流程需经过直接主管和部门经理两级审批。", "《Q3 发布说明书》：我们于 2023 年 10 月发布了名为 'Nebula AI' 的智能助手。", "《Q3 发布说明书》：'Nebula AI' 支持自然语言处理和多模态交互。" ] # 将文本分块 (Chunking) chunks = split_text(documents) # 将文本转化为向量 (Embedding) 并存入向量数据库 (如 Pinecone, Milvus) for chunk in chunks: vector = embedding_model.encode(chunk) vector_db.upsert(id=chunk.id, vector=vector, metadata=chunk) 2. 用户提问（Query） 用户输入："我报销差旅费需要几个人审批？另外，Q3 发布的 AI 助手叫什么名字？" ...