1. 从“你好”到“理解”一次对话背后的技术拆解当你在聊天框里输入“你好”点击发送屏幕另一端的AI助手回复“你好有什么可以帮你的吗”这个过程看似简单背后却是一系列精密技术概念协同工作的结果。这不仅仅是字符串的传递而是一场从人类语言到机器理解再到机器执行和回应的复杂“翻译”与“协作”。对于任何希望深入理解或应用大语言模型LLM的开发者、产品经理乃至技术爱好者来说厘清几个核心概念是构建有效对话系统的基石。这些概念就是Token、Prompt、Embedding 和 Function Calling。它们分别扮演着不同的角色Token是AI“阅读”文本的基本单位Prompt是你与AI沟通的“指令集”Embedding是将文字转化为机器能“感受”的数学向量的魔法而Function Calling则是让AI从“空谈”走向“实干”的桥梁。理解它们你就能明白为什么你的提问有时得不到想要的答案也能学会如何更精准地“调教”AI让它不仅能对答如流还能帮你查天气、订日程、分析数据。接下来我们就抛开晦涩的术语用最直白的方式把这四个概念掰开揉碎讲清楚。2. Token大模型世界的“识字卡片”如果把大语言模型比作一个正在学习阅读的超级大脑那么Token就是它用来认字的“识字卡片”。这不是我们通常理解的“单词”而是一种更细粒度的文本切分单元。2.1 Token的本质超越单词的文本切片在英文中一个Token可能是一个完整的单词如“hello”也可能是一个词根或词缀如“un-”, “-ing”甚至是一个标点符号。在中文里由于没有空格分隔分词本身就是一个复杂任务因此一个Token通常对应一个汉字或常见的词组。例如“人工智能”可能被切分为“人工”和“智能”两个Token也可能在某些分词规则下被视为一个Token。大模型如GPT系列、Claude、文心一言等在训练前会用一个称为“Tokenizer”分词器的工具将海量的文本数据切割成Token序列。每个Token会被分配一个唯一的ID。模型并不直接“认识”文字它认识的是这些ID并通过海量数据学习这些ID序列之间的概率关系。当你输入“今天天气不错”模型内部处理的其实是类似[101, 102, 103, 104]这样的ID序列。注意不同的模型使用不同的分词器。例如OpenAI的GPT系列使用基于字节对编码BPE的tiktoken而一些开源模型可能使用SentencePiece。这意味着同样的文本在不同模型下的Token数量和切分方式可能不同这会直接影响API调用成本按Token计费和模型的理解上限上下文窗口大小。2.2 Token的实战意义成本、长度与效率理解Token对于实际应用有三大直接影响成本计算几乎所有商业LLM API的计费都基于Token数量。输入Prompt和输出Completion的Token数总和决定了每次调用的费用。因此优化Prompt减少不必要的Token是控制成本的关键。例如用“简述”代替“请用简短的语言概括一下”就能节省好几个Token。上下文窗口限制模型的“记忆力”是有限的这个限度就是上下文窗口Context Window通常以Token数表示如4K、8K、32K、128K、1M。你的对话历史、系统指令、用户问题、模型回答所有内容的总Token数不能超过这个限制。超过的部分模型将“遗忘”最早的信息。因此在设计长对话应用时必须考虑如何精炼信息或实现历史记忆的滚动与总结。处理效率Token化的质量直接影响模型的理解。糟糕的分词如将专业术语切分得支离破碎会导致模型产生困惑输出质量下降。这也是为什么有些领域如医疗、法律需要专用分词器或进行领域词汇扩充的原因。一个常见的坑用户发现模型突然“失忆”不记得几分钟前的对话内容了。这很可能不是因为模型 bug而是因为累积的Token数超过了上下文窗口最早的历史消息被自动截断了。解决方案包括主动在Prompt中要求模型总结之前的对话关键点或者在应用层设计机制定期将长对话摘要后作为新的系统提示输入。3. Prompt与AI沟通的“元指令”如果说Token是砖瓦那么Prompt就是用这些砖瓦搭建起来的、给AI的“施工图纸”。Prompt Engineering提示工程的核心就是学习如何绘制这份图纸让AI能准确无误地建造出你想要的“房子”。3.1 Prompt的构成不止是问题本身一个有效的Prompt远不止是抛出一个问题。它通常是一个结构化的文本包含多个部分共同引导模型的行为。一个经典的Prompt结构可能包括系统指令System Prompt定义AI的“角色”和对话的“基本法”。例如“你是一个严谨的科技文章翻译助手擅长将复杂的英文技术文档转化为流畅、准确的中文。你会保留所有专业术语的英文原名并在括号内提供中文翻译。” 这部分内容通常在对话开始时一次性设定对整个会话过程产生全局性影响。用户指令User Instruction即用户本次的具体请求。它应该清晰、具体、无歧义。上下文信息Context为完成指令所需提供的背景材料、参考数据等。例如让AI总结一篇长文章你需要先把文章内容作为上下文提供给它。输出格式要求Format明确指定你希望AI以何种形式回复。例如“请以Markdown表格形式列出优缺点第一列是项目第二列是说明。”示例Few-Shot Examples提供一两个输入-输出的例子让模型通过“示例学习”快速掌握你的要求。这对于复杂或格式特殊的任务尤其有效。3.2 提示工程的核心技巧从模糊到精确为什么有时候AI的回答不尽如人意问题往往出在Prompt不够“到位”。以下是几个提升Prompt质量的实战技巧具体化避免模糊不要问“写点关于人工智能的东西”而是问“以科普风格为高中生写一段300字左右的文字介绍机器学习中的监督学习概念并举例说明”。分步骤思考Chain-of-Thought对于逻辑推理或复杂计算问题在Prompt中鼓励模型“一步步思考”。例如“请计算一个边长为5cm的立方体的体积。请先写出公式再代入数值计算最后给出答案。” 这能显著提升模型在数学和推理任务上的准确性。设定约束与边界明确告诉模型“不要做什么”。例如“在回复中不要使用任何Markdown格式。”“仅基于我提供的以下资料进行回答不要引入外部知识。”利用分隔符清晰划分结构使用---、、###等符号将系统指令、上下文、问题分隔开帮助模型更好地解析你的意图。一个我踩过的坑早期做一个客服机器人时我只给了系统指令“你是友好客服”但用户问“我的订单还没到火大”模型回复“听起来您遇到了物流问题这确实令人沮丧。让我们看看如何解决...”虽然友好但不够高效。后来我优化了Prompt“你是高效、专业的电商客服助手。目标是快速定位问题并提供解决方案。用户表达情绪时先简短共情不超过10个字然后立即转向事实询问1. 订单号2. 下单日期3. 遇到的问题现象。” 调整后模型的回复立刻变得目标明确、行动导向。4. Embedding让文字拥有“向量灵魂”Token和Prompt处理的是文本的“形式”而Embedding嵌入解决的则是文本的“内涵”问题。它的目标是将文字或Token转换为计算机能真正“理解”和“比较”的形态——高维空间中的向量一组数字。4.1 Embedding的工作原理从离散符号到连续空间想象一下每个单词或句子都被映射到一个多维坐标系中的一个点。在这个空间里语义相近的文本它们的点距离就近语义无关的文本点距离就远。例如“国王”的向量减去“男人”的向量再加上“女人”的向量结果会非常接近“女王”的向量。这就是Embedding创造的“语义空间”。这个过程通常由一个专门的神经网络模型即Embedding模型如OpenAI的text-embedding-ada-002开源的BGE、Sentence-Transformers来完成。模型接收文本输入输出一个固定长度的浮点数向量如1536维。这个向量凝练了该文本的语义信息。4.2 Embedding的核心应用检索、聚类与推荐Embedding是让AI应用“有记忆”、“能联想”的关键技术主要应用在语义搜索与检索增强生成RAG这是当前最火的应用。传统关键词搜索匹配的是文字本身而基于Embedding的语义搜索匹配的是“意思”。你可以将公司内部文档、知识库全部转化为向量存入数据库如Pinecone、Chroma、Milvus等向量数据库。当用户提问时将问题也转化为向量然后在向量数据库中快速查找“意思”最相近的文档片段将这些片段作为上下文提供给LLM让LLM基于这些准确信息生成答案。这极大地解决了LLM“幻觉”胡编乱造和知识过时的问题。文本聚类与分类通过计算大量文本的Embedding可以利用聚类算法如K-Means自动将相似主题的文档归为一类无需预先定义标签。个性化推荐将用户的历史浏览内容、商品描述转化为向量通过向量相似度匹配可能感兴趣的新内容。选择Embedding模型的考量点维度通常维度越高表征能力越强但计算和存储成本也越高。上下文长度模型能处理的最大文本长度如512 tokens, 8192 tokens。性能MTEB等榜单在公开基准测试上的表现衡量其语义理解能力的强弱。速度与开销有些轻量级模型适合端侧部署而大型模型更适合云端服务。语言与领域是否有针对特定语言如中文或特定领域如生物医学优化的版本。实操心得在搭建RAG系统时分块Chunking策略和Embedding模型的选择同样重要。简单粗暴地按固定长度如500字切分文档可能会把一个完整的概念拦腰截断。更好的做法是尝试按段落、按标题层级进行切分或者使用更智能的语义分割算法。同时查询语句的Embedding和文档块的Embedding最好使用同一个模型生成以保证向量空间的一致性。5. Function CallingAI的“手脚”与“工具包”LLM很擅长理解和生成文本但它无法直接操作现实世界——它不能帮你查数据库、发邮件、调用天气预报API。Function Calling函数调用就是为了解决这个问题而生的机制。它让LLM能够根据对话内容“思考”出需要调用哪个外部工具函数并生成符合该工具要求的结构化参数然后由应用程序去实际执行这个函数最后将执行结果返回给LLM由LLM组织成自然语言回复给用户。5.2 Function Calling的工作流程一次完整的“思考-执行-回复”这个过程是一个典型的智能体Agent工作流用户请求用户说“北京今天天气怎么样”模型“思考”与决策LLM分析对话发现需要实时天气数据。它“知道”通过开发者预先提供的函数描述有一个叫get_current_weather的函数可以满足这个需求。生成调用请求LLM不会直接执行代码而是输出一个结构化的JSON对象例如{ function: get_current_weather, arguments: { location: 北京, unit: celsius } }应用层执行你的应用程序收到这个JSON后解析它并在后端安全地调用真实的get_current_weather函数该函数可能调用一个天气API。返回结果函数执行后返回结果例如{temperature: 22, condition: 晴朗, humidity: 65}。模型组织回复应用程序将这个结果作为新的上下文信息传给LLM。LLM据此生成最终的用户回复“北京今天天气晴朗气温22摄氏度湿度65%是个好天气。”5.3 设计高效Function Calling的关键要让Function Calling顺畅工作关键在于如何向LLM描述这些函数清晰的函数名与描述函数名和描述要直观地反映其功能。例如get_current_weather就比query_data好得多。严谨的参数模式Schema定义使用JSON Schema精确描述每个参数的名称、类型、是否必需、枚举值以及含义说明。这对于模型正确生成参数至关重要。{ name: get_current_weather, description: 获取指定城市的当前天气信息, parameters: { type: object, properties: { location: { type: string, description: 城市名称例如北京、上海 }, unit: { type: string, enum: [celsius, fahrenheit], description: 温度单位, default: celsius } }, required: [location] } }处理多函数与冲突当提供多个函数时LLM需要选择最合适的一个。清晰的描述能帮助它做出正确判断。有时用户请求可能模糊模型可能会要求用户澄清或者尝试调用一个函数这需要应用层做好错误处理和重试逻辑。一个高级技巧让AI自己决定是否调用工具。不是所有用户输入都需要触发Function Calling。你可以在系统Prompt中明确告诉模型“你拥有调用工具的能力。只有当用户的问题明确需要实时数据、计算或无法仅凭内部知识回答时你才应该决定调用函数。否则请直接基于你的知识回答。” 这可以避免不必要的API调用提升响应速度和降低费用。6. 概念串联构建一个智能问答助手的实战推演现在让我们把这四个概念串联起来看它们如何在一个具体的应用场景——搭建一个基于企业知识库的智能问答助手——中协同工作。6.1 场景设定与流程设计假设你是某科技公司的开发人员需要构建一个内部助手能回答员工关于公司规章制度、项目文档、技术API等问题。核心要求是答案准确基于最新文档、成本可控、响应快速。整个系统的工作流程如下知识库预处理离线Embedding主场文档收集与清洗收集所有相关的PDF、Word、Confluence页面、Markdown文件。文本提取与分块从文件中提取纯文本并采用合理的分块策略如按章节/按语义切割成大小适中的文本块Chunks。向量化使用一个强大的Embedding模型例如BGE-large-zh针对中文优化将每一个文本块转化为向量。存入向量数据库将这些(文本块 对应向量)对存入像Chroma或Milvus这样的向量数据库中建立索引以便快速检索。用户问答流程在线四概念联动Step 1: 接收用户Query员工提问“我们公司申请年假的流程是什么需要提前几天申请”Step 2: Query的Embedding与检索系统将用户问题同样用BGE-large-zh模型转化为向量。在向量数据库中执行相似度搜索找出与问题向量最接近的Top K个比如3个文档块。这些文档块就是最相关的知识片段。Step 3: 构建增强Prompt系统组装最终的Prompt给大语言模型如GPT-4或开源Llama 3。系统指令“你是一个专业、准确的公司内部助手。请严格根据提供的参考信息回答问题。如果信息不足请明确告知‘根据现有资料无法找到相关信息’切勿编造。”上下文将检索到的3个相关文档块内容插入此处。用户问题原始的用户问题。输出要求“请用清晰、有条理的列表或步骤形式回答。”Step 4: 大模型生成回答大模型基于这个包含了精准上下文的Prompt生成一个准确、有据可依的回答例如“根据公司《员工手册》第X章规定年假申请流程如下1. ... 需至少提前3个工作日提交申请。”Step 5: 可选Function Calling扩展如果员工进一步问“帮我查一下我今年还剩多少天年假”单纯的RAG就无法回答了因为这是需要查询个人数据库的。这时就需要引入Function Calling。系统需要预先定义一个函数get_remaining_annual_leave(user_id)并在Prompt中将其描述提供给模型。模型在对话中识别出这个需求会生成调用该函数的请求由后端系统执行查询后再将结果{remaining_days: 5}返回给模型由模型组织成最终回复“根据系统记录您本年度剩余年假为5天。”6.2 技术选型与权衡思考在这个架构中每个环节的选择都充满了权衡Embedding模型选型为什么选BGE-large-zh而不是OpenAI的text-embedding-3主要考虑可能是1)数据隐私所有文档和问答数据都在内网处理无需出境。2)成本自托管开源模型一次投入无限次使用长期看比按次付费的API更经济。3)针对性专门针对中文优化的模型在中文语义相似度任务上表现可能更佳。大模型选型为什么可能选择GPT-4而不是更小的模型因为问答任务需要较强的语言理解、逻辑组织和遵循指令的能力。虽然成本更高但为了答案的准确性和可靠性这笔投入是值得的。对于更简单的任务也可以考虑使用ChatGLM、Qwen等优秀的开源模型来降低成本。分块策略这是影响RAG效果的关键“暗箱”。经过多次实验我们发现对于混合了标题、段落、列表的Confluence页面采用“递归字符文本分割器”按标题层级分割效果优于固定长度分割。它能更好地保持单个语块的语义完整性。6.3 避坑指南与性能优化在实际部署中我们遇到了几个典型问题及解决方案检索精度不足“搜不准”问题有时检索到的文档块看似相关但并未包含回答问题的关键信息。排查检查Embedding模型是否适合你的领域检查分块是否合理是否切断了关键信息尝试在检索时使用“多查询检索”技术即让大模型根据原始问题生成几个不同角度的子问题分别检索后再合并结果。解决我们引入了“重排序Re-ranking”模型。即先用Embedding模型进行“粗筛”召回大量相关文档如Top 20再用一个更精细的、专门判断相关性的重排序模型如BGE-Reranker对这20个结果进行精排只取Top 3给大模型。这显著提升了上下文质量。回答出现幻觉“瞎编”问题即使提供了上下文模型有时还是会编造一个看似合理但错误的答案。排查强化系统指令使用更严厉的措辞如“你必须引用参考信息中的原话并注明出处”。在Prompt中明确告知模型如果答案不在上下文中必须说不知道。解决在应用层增加“答案溯源”功能。要求模型在生成答案时必须引用它所用到的文档块ID。这样前端可以展示引用的原文片段方便用户核对也增加了系统的可信度。响应延迟大问题从提问到获得答案耗时超过5秒体验差。排查对链路进行分段计时。发现耗时大头在1) 向量数据库检索2) 大模型生成。解决对于检索确保向量数据库建立了高效的索引如HNSW。对于大模型生成可以尝试使用其更快的版本如GPT-3.5-Turbo用于简单问答GPT-4用于复杂分析或者对答案长度进行限制。同时引入流式输出Streaming让用户能边生成边看到部分答案感知上会更快。通过这样一个完整的项目推演你可以清晰地看到Token、Prompt、Embedding、Function Calling不再是孤立的概念而是像齿轮一样咬合在一起共同驱动着一个智能、实用、可落地的AI应用。理解它们各自的原理和相互间的协作关系是你在AI应用开发道路上从入门到精通的必经之路。