AI 入门：从一个图书馆助手说起

“周末有什么适合小学生的活动？还有没有名额？”

设想一家图书馆准备做一个活动助手。读者在聊天框里问了这么一句，工作人员还想让它写活动介绍、整理报名信息。都是平常的要求，背后需要的本领却不一样。

写介绍，要把话组织好；推荐活动，要知道本周的排期；回答还有没有名额，得去报名系统里查。同一个助手，要靠模型、检索和工具一起完成这些事。文首的关系图画的就是它们怎样配合，先从写介绍说起。

大语言模型：负责生成的那一部分

图书馆提供活动信息，大语言模型（Large Language Model，LLM）可以帮忙写成一段介绍。它只是 AI 的一部分：识别图片、推荐音乐、预测设备故障，也都可能用到 AI。这篇先聊大语言模型及其应用，其中一些模型也能接收图片、音频等输入。

可以把模型看成一位编辑，把 AI 产品看成整个编辑部。编辑会写文章，可要找到资料、核实消息、联系外部系统，还得有人和设施配合。接上搜索、文件读取和工具调用以后，产品能做的事，就超出了模型单独生成文字的范围。

模型的能力主要来自训练。它内部有大量数值，叫作参数；训练会调整这些数值，改变模型处理输入的方式。预训练让模型从大量样本中学习语言和知识的规律，后续训练则可以让它更好地按要求作答、完成特定任务。

常见的自回归语言模型，会根据已有内容计算下一个 Token 的概率，再按解码策略逐步生成。使用训练好的模型处理输入、产生输出，工程上称为推理（Inference）。生成一句问候也算“推理”，这个词不专指逻辑推理（Reasoning）。模型是在运行，回答一次并不等于重新训练一次。^[1]

至于它能把介绍写得多好，还得拿实际任务来试。仅凭逐个生成 Token 的机制，无法判断它“只是在接词”，还是“已经像人一样理解世界”。在这个图书馆助手里，我们先看得到的结果：介绍是否好懂，判断是否符合拿到的材料。

提示词、Token 和上下文

如果交给编辑的要求只有“写一段活动介绍”，他得猜不少事情。改成“写给第一次带孩子来图书馆的家长，说明年龄要求和报名方式”，读者和用途就清楚多了。模型也需要这样的交代。问题、任务说明、示例等输入，通常都属于提示词（Prompt）。

应用还可以通过系统提示词（System Prompt）设定角色和行为要求，比如用什么语气回答、资料不足时怎么办。模型有没有遵守，需要检查；谁能查哪些数据、允许执行什么操作，则要在应用里设置权限和校验，光写进提示词不够。^[2]

编辑接到任务，总要有个地方摊开材料。模型在当前调用中实际拿到的内容，叫作上下文（Context）。指令、问题、被带入的历史对话，以及可能用到的检索资料、工具说明和工具返回结果，都放在这里。

就像一张工作桌，这次交来的材料得摆在上面，模型才能参考。软件即使保存了完整聊天记录，也不一定每次调用都把它全部搬上来。

材料能放多少，通常要用 Token 来计量。Token 常译为“词元”，是文本经过分词器处理后使用的单位。它可能是一个词、词的一部分，也可能是字符或字节片段，不能与汉字、英文单词一一对应。要准确计数，就得用相应模型的分词器或计数接口。^[3][17]

一次调用能够容纳的内容范围，叫作上下文窗口（Context Window）。具体是否连输出一起计入，要看模型接口。窗口快满时，应用可能删减历史、生成摘要，也可能直接报错；各家产品不会按同一套规则“自动遗忘”。^[4]

桌子大些，能多放纸，找重点却未必更容易。资料仍要整理好，说明来源和用途。长期记忆也常这样安排：先把信息保存在模型之外，等需要时再找回来，放进当前上下文。

幻觉：把虚构的内容说得像真的

现在，假设助手没有拿到排期，却一本正经地回答：“周六下午两点，少儿阅览室举行读书会。”图书馆当天根本没安排这项活动，家长照着去，就可能白跑一趟。

这就是一种典型的幻觉（Hallucination）。回答像模像样，里面却有错误、虚构，或与所给材料不符的内容。^[5]

核对时，要查活动有没有安排、时间地点对不对，以及回答有没有超出材料能支持的范围。没附来源，只能说明还需要核实，不能据此认定它在编造。

模型学会了活动介绍的写法，不代表它知道这家图书馆本周要干什么。训练数据、上下文和生成方式都可能影响错误的出现。得把相关资料或查询结果交给它；资料不够时，也要允许它回答“查不到”或“尚未确定”。

RAG、Embedding 与向量检索

那就先把排期找来。

图书馆可以整理一份活动资料库，收到问题后，先找到相关条目，再让模型参考这些内容作答。这种办法叫 RAG，全称是 Retrieval-Augmented Generation，中文称“检索增强生成”。把检索材料放进上下文，本身不会更新模型参数。^[6]

实际做时，通常先把文档整理成便于查找的片段，留下标题、日期和来源。提问来了，系统找出候选材料，必要时重新排序，再选出合适的交给模型。检索决定了模型会读到什么，因此答错时也要回头看它拿到的材料。

可读者不一定照着排期上的词来问。“小学生周末能参加什么”，可能对应的是“儿童阅读工作坊”。字面不同，意思却有关联。

Embedding 可以帮助处理这种情况。它通常译为“嵌入”；在文本检索里，就是用一组数值表示一段文本，让系统能够比较问题和资料的相似程度。

可以把这些向量想成地图上的坐标。合适的 Embedding 模型，会让相关内容在这张图上更容易被找到。不过，这些坐标是模型学出来的表示，靠得近只是提示内容可能相关，不表示资料一定真实。^[7]

保存、索引和查询这些向量，是向量数据库或支持向量检索的数据库负责的事。也未必需要另换一套数据库，PostgreSQL 就可以通过 pgvector 扩展增加向量搜索能力。^[8]

RAG 也不只认向量。查活动编号、日期或精确名称，关键词检索往往很有用；问法不同而意思相近，可以借助语义检索。把两种方式结合起来，就是混合检索。^[6][7]

“儿童活动取消通知”和“儿童活动安排”也可能很相近。多了“取消”两个字，家长这趟还要不要去，可就完全不同了。检索找到相关材料之后，还要读清日期、适用范围和具体意思，确认来源可靠、回答没有曲解原文。

微调：通过训练改变模型

助手反复答错，值得再训练一下吗？

先看它错在哪里。图书馆每周换排期，首先需要的是资料及时更新、查询准确。如果资料已经给全，模型仍总是做不好同一类任务，可以先调整提示和示例，再考虑微调。

微调（Fine-tuning）是在已有模型基础上继续训练，让它更适应某类任务或数据。有的方法调整原有参数，有的只训练少量新增参数。它可以影响表达方式、任务能力和领域知识，作用不限于模仿语气。^[9][18]

还用编辑部来比喻，RAG 是给编辑准备这次要参考的资料，微调则像通过练习改变他处理任务的习惯和能力。两件事可以一起做，接受过针对性训练的模型，也可以继续查询最新资料。^[6]

把一份活动表拿去微调，也不会自动得到一本随时更新的活动台账。模型以后仍要知道排期改了什么，这部分工作还得由资料更新和查询来完成。

工具调用与结构化输出

排期找到了，读者接着问：“还有没有名额？”

这次，光读文档就不够了。余位在变，需要去报名系统里查。应用可以给模型一个“查询活动余位”的工具，说明它能做什么、需要哪些参数。模型提出调用请求，应用程序或相应运行环境执行查询，再把结果送回来。

这通常叫工具调用（Tool Calling）。如果请求用函数名和参数来表达，也常叫函数调用（Function Calling）。各个平台的叫法可能不同，需要分清的是：提出请求和实际执行，由谁完成。^[10]

就像编辑请人去查剩余名额，得等那个人查过系统、带回结果才能写。查询可能失败，数据可能过期，也可能查到了同名的另一场活动。这些都会影响最后的回答。

查回来的内容，往往还要交给其他程序处理。人能读懂一段话，程序可能需要固定字段，比如活动名称、日期、适龄范围和剩余名额。结构化输出（Structured Output）就是为了让这些结果更容易被程序读取。JSON Schema 等机制能规定字段、数据类型和必填项，比只说一句“请输出 JSON”约束得更明确。^[11]

格式规定好了，内容仍可能填错。把周日写成周六，也能交出合规的表格；“剩余名额”填了整数，也未必查过报名系统。检查字段以外，还要把内容与实际查询结果对上。

Workflow 与 Agent：下一步由谁决定

从读排期到写介绍，再检查必填项、保存草稿，这些步骤可以事先安排好，做成工作流（Workflow）。工作流也可以有条件分支、重试和循环，关键是处理路径由程序预先规定。

如果查询发现活动已经报满，接下来要不要找替代活动、还缺哪些条件，也可以让模型根据情况决定。

在大模型应用里，这类让模型在目标和约束下动态安排执行路径、选择工具的系统，通常称为 Agent，中文常译作“智能体”。它观察运行结果，再决定继续检索、调用工具、回答问题，还是请求补充。^[12]

步骤清楚的任务，适合先写好工作流；临时变化多，可以让模型多作一些决定。两种安排也能一起用：外层程序规定哪些信息必须核对，模型选择怎样查找。辨别一个系统是不是 Agent，要看哪些决定交给了模型，光看步骤多、有循环还不够。

把决定交出去，也得说明什么时候停。查询没结果，是再试一次，还是请人处理？这些限制需要在运行前考虑好。

验收时，可以看它查了哪些资料、工具返回了什么、交付是否满足要求，无需展示全部内部推理。计划告诉我们它准备做什么，执行记录才说明它实际做过什么。

MCP 与 Skill：接口和工作手册

报名系统、资料库和其他服务越接越多，每个接口都单独适配，维护起来也会越来越费事。MCP 要处理的是其中一部分连接问题。

MCP 的全称是 Model Context Protocol，通常译为“模型上下文协议”。它是一套让 AI 应用连接外部工具和数据资源的开放协议，支持协议的客户端与服务器可以按约定交换工具、资源等信息。^[13]

统一接口能减少一部分重复对接。工具具体能做什么、谁有权使用，仍要由应用和服务端处理。Function Calling 关注模型怎样提出调用请求，MCP 关注应用怎样连接、交换相关信息。应用也完全可以直接调用自己的 API，不经过 MCP。

工具接进来了，还需要交代工作怎么做。这里说的 Skill，是采用 Agent Skills 开放格式的技能包，核心是一份 SKILL.md 说明文件，也可以附带脚本、模板和参考资料，由支持它的应用按需加载。^[14]

它像编辑部的工作手册，写明活动介绍有哪些要求、哪些信息必须核对、何时运行检查脚本。把手册拿来读，本身不会更新模型权重，也不会另启动一名 Agent。

Skill 可以使用 MCP 提供的工具，也可以调用其他工具，或者只提供写作方法。它们能配合，也能分别使用，并不是必须一层一层往上搭。

评估：从同一个错误查起

模型、资料和工具都接上了，回答还是可能出错。

还是看那场已经取消的活动。假设助手仍然在推荐，只盯着最后一句回答，很难知道该改哪里。得回去看看，它当时到底拿到了什么。

资料库里只有旧排期，就先修资料更新；库里有取消通知，却没检索出来，就检查检索；明确的取消通知已经放进上下文，回答还在推荐，再查模型是否漏读、指令是否造成误解，或后续程序是否丢掉了信息。

同样一句错误答案，可能出在不同环节。换个模型、把提示词加长，也许碰巧答对一次，却没有解决原来的问题。对照文首的关系图，看资料怎样送到模型手里、工具又返回了什么，才容易找到该改的地方。

把这场活动的资料、读者的问题和预期回答留下，就有了一道能反复检查的题。再加入排期明确、资料过期、问法不同，以及现有资料答不了的问题，逐渐形成一组评估任务。评估（Evaluation，常简称 Eval）需要输入与判断标准，也可以检查工具调用过程和外部系统的实际结果。^[15]

取消了，就应停止推荐；没写年龄限制，就保留未知；查询余位，要对上正确的活动和时间。改过检索、提示或模型后，用同一组题比较，看看错误发生的位置有没有变化。题目可以先少一些，但要知道已经检查了什么。

初学时，可以先让助手查一条排期、附上来源，自己核对一下，等这一步稳妥了再接入报名系统。读者问的还是“还有没有名额”。现在若回答错了，至少知道该去看资料、模型，还是那次查询。