大模型学习大模型核心原理大模型提示工程 7、用 GPTs 帮我们写 prompt_哔哩哔哩_bilibili key:

克服上下文窗口限制：这是最直接的原因，目前所有的大预言模型，无论是GPT系列、Claude还是Llama,都有其能够一次性处理的上下文长度限制。原始文档往往远超这个限制（几千到几十万tokens不等),如果不分块，根本无法将完整的长文档信息有效地提供给LLM，分块确保了输入的信息能在消化范围之内。
提高检索精度和效率：精度，一个精确的包含该定义的、几百字的chunk显然比包含整个概括性文档的chunk更容易被检索算法命中。大块内容无关信息多，会稀释相关信号。效率，对大量小块文本进行向量化和索引，构建向量数据库，其检索速度通常远快于在整个原始文档集合中进行搜索。
维护上下文完整性:虽然我们要切分，但理想的分块策略并非随意切分，应尽可能保持语义的连贯性和上下文的完整性。

文档分割的策略有：

固定大小分块：这是最简单的方法，直接按照固定的字符数或者Token数量来切割文本。为了缓解在边界处强行切断语义的问题，通常会设置一个“重叠”(overlap)大小，重叠部分意味着每个块的末尾会与下一个块的开头有一段重叠的部分。 核心思想：设定一个 chunk_size（如 500 个字符）和一个 chunk_overlap（如 50 个字符）。从文本开头取 chunk_size 个字符作为第一个块，然后下一次从 start_index + chunk_size - chunk_overlap 的位置开始取下一个块，依此类推。优点：
实现极其简单，几乎不需要复杂的逻辑。
计算开销非常小，处理速度快。
对文本格式没有特殊要求。

缺点：

极易破坏语义完整性：非常可能在句子中间、单词中间（如果按字符切）、代码行中间等不恰当的地方断开，导致上下文严重割裂。 - 忽略文本结构：完全无视段落、标题、列表等任何文本固有结构。固定大小对于信息密度不同、语言不同的文本效果可能差异巨大。同样的 500 字符，在信息密集的文本中可能只包含半个观点，在稀疏文本中可能包含好几个。

适用场景：

- 对文本结构要求不高的简单场景。
- 数据量极大，需要快速进行初步处理时。
- 作为更复杂分块策略（如递归分块）的最后“兜底”手段。
- 对上下文完整性要求不高的检索任务。

基于句子的分块

这种策略试图尊重语言的自然边界——句子。它首先使用句子分割算法（如基于标点符号 .?!，或使用 NLP 库如 NLTK, SpaCy）将文本分割成独立的句子，然后将一个或多个连续的句子组合成一个 Chunk，使其大小接近目标范围。

核心思想：先切分成句子，再合并句子成块。可以简单地每个句子是一个块，也可以设定一个目标块大小，将连续的句子合并，直到接近该大小。同样可以引入句子级别的重叠（如一个块包含第 1-3 句，下一个块包含第 3-5 句）。
优点：
- 更好地保持语义完整性：因为句子是表达相对完整意思的基本单位，所以很少会在句子内部断开。
- 比固定大小分块更符合自然语言的结构。
缺点：
- 句子长度差异大：有的句子很短，有的很长，导致 Chunk 大小不均匀，可能影响后续处理和检索稳定性。
- 简单的基于标点的分割可能不准确（例如，Mr. Smith 中的 .）。需要更可靠的 NLP 工具。
- 对于代码、列表、或者没有明确句子结构的文本（如 JSON, YAML）效果不佳。
- 跨越多个句子的复杂语义关系可能仍然被切断。
适用场景：
- 处理结构良好、以完整句子为主的文本，如新闻文章、报告、小说等。
- 当保持句子层面的语义完整性比较重要时。

递归字符分块这是 LangChain 等框架中常用的一种更智能的策略。它试图按一个预设的“分隔符”优先级列表来递归地分割文本。

核心思想：提供一个分隔符列表，按优先级从高到低尝试分割。例如，优先尝试按 \n\n (段落) 分割，如果分割后的块仍然太大，再尝试按 \n (换行符) 分割，然后按空格 `` 分割，最后如果还太大，就按字符 "" 分割。目标是在保持较大语义块（如段落）的同时，确保最终块大小不超过限制。
优点：
- 试图保持语义结构：优先使用段落、换行等更有意义的分隔符，尽可能维持文本的逻辑结构。
- 比固定大小更智能：避免在不必要的地方断开。
- 适应性强：对不同类型的文本结构（段落、列表等）有一定适应性，是固定大小和句子分割的一种折中和改进。
缺点：
- 实现相对复杂一些。
- 效果依赖于分隔符列表的选择和优先级顺序。
- 对于没有明显分隔符的密集文本，可能最终退化为按字符分割。
适用场景：
- 通用性较好，适用于多种类型的文本文档。
- 当希望在控制块大小的同时尽可能保留文本结构时。
- 许多 RAG 框架的默认或推荐选项。

基于文档结构的分块这种策略利用文档本身的结构信息进行分割，例如 HTML 的 <div>, <p>, <li> 标签，Markdown 的标题 #, ##, 列表 -, *，或者 JSON/YAML 的层级结构。

核心思想：解析文档的结构树或特定标记，基于这些结构元素来定义 Chunks。例如，每个 <p> 标签内容作为一个 Chunk，或者每个 Markdown 的二级标题下的所有内容作为一个 Chunk。
优点：
- 高度尊重原文结构：能够最好地保持作者组织信息的方式。
- 语义连贯性强：通常一个结构元素（如段落、列表项）包含一个相对独立的语义单元。
- 可以方便地将结构信息（如标题、标签）作为元数据（Metadata）附加到 Chunk 上，这对后续检索很有帮助。
缺点：
- 依赖于清晰、一致的文档结构：如果文档结构混乱或没有明确标记，则效果不佳。
- 不同结构元素的文本量可能差异巨大，导致 Chunk 大小极不均匀。例如，一个段落可能很短，另一个章节可能很长。
- 需要针对不同的文档格式（HTML, Markdown, LaTeX, JSON...）编写不同的解析逻辑。
适用场景：
- 处理具有清晰、标准化结构的文档，如网页、Markdown 文档、结构化数据（JSON/XML）等。
- 当需要利用文档结构信息进行检索或过滤时。

混合分块顾名思义，混合策略结合了上述两种或多种方法的优点，试图达到更好的平衡。一个常见的组合是：首先尝试基于文档结构（如 Markdown 标题）进行高级别分割，然后在这些较大的分割块内部，如果它们仍然超过了目标大小，再使用递归字符分块或句子分块进行细粒度的切分。

核心思想：分层处理。先用结构化或语义边界（如标题）做粗粒度切分，得到逻辑上相关的“大块”，再对这些“大块”应用更细粒度的策略（如递归字符分割）来满足大小限制，同时保留“大块”的上下文信息（如将标题作为元数据）。
优点：
- 兼顾结构与大小限制：既能利用文档的宏观结构，又能确保最终块大小可控。
- 元数据丰富：可以方便地继承来自结构化分割的元数据（如标题层级）。
- 灵活性高，可根据需求定制组合策略。
缺点：
- 实现复杂度相对较高。
- 需要仔细设计组合逻辑和参数。
适用场景：
- 对分块质量要求较高，希望在保持上下文、利用结构和控制大小之间取得良好平衡的场景。
- 处理像 Markdown、富文本文档这样既有结构又有自由文本的内容。

语义分块当基础策略无法满足更复杂的需求时，或者当你想追求极致的检索效果时，可以探索以下更高级的分块方法。这些方法通常更侧重于语义理解或利用更复杂的模型/流程。

核心思想：这种方法不看字数、不看标点，而是看“意思”。它会计算相邻句子或小段文字的 Embedding 向量，看看它们在语义上有多接近。当发现前后两部分的“话题”跳跃比较大（语义相似度低于某个设定的“阈值”）时，就在这个“语义断裂点”进行切割。
优点：切分点更“懂”语义，总能在话题自然转变的地方下手。这样能保证每个 Chunk 内部意思高度相关、不跑题，理论上切出来的块更符合人的阅读理解习惯。
缺点：要算 Embedding，计算开销比前面那些简单方法大得多。效果好坏非常依赖 Embedding 模型本身的能力，而且那个“语义距离阈值”得靠实验慢慢调，有点麻烦。处理速度也比较慢。
适用场景：对分块质量要求很高，并且计算资源比较充裕的场景。特别适合处理那些没什么结构化标记（比如纯文本、对话记录），但意思很丰富的长文。

实现思路举例：一种可能的做法（去年我记得Langchain是这样）是，不比较单个句子，而是把连续的几个句子（比如 3 句）看成一个“语义单元”，计算这个单元的 Embedding，然后比较相邻“单元”之间的语义距离。

分层分块

核心思想：类似于混合策略，但更系统化地创建多个层级的 Chunks。例如，可以先将文档按章节分割成大块（L1 Chunks），再将每个章节按段落分割成中块（L2 Chunks），最后可能按句子分割成小块（L3 Chunks）。这些不同层级的 Chunks 可以被索引，并用于不同的检索策略（见下文 Small-to-Big）。
优点：提供了不同粒度的上下文信息，增加了检索的灵活性。
缺点：增加了索引的复杂度和存储空间。需要设计好多层级之间的关系和使用方式。
适用场景：需要处理具有清晰层级结构的复杂文档（如书籍、长篇报告），并且希望在检索时能灵活选择上下文粒度。

Small-to-Big 检索 / 父文档检索器

核心思想：这严格来说是一种检索策略，但它依赖于特定的分块方式（通常是分层或存在父子关系的块）。基本流程是：

将文档分割成小块 (Small Chunks)，这些小块适合进行精确的向量相似度检索。
同时，保留或链接到这些小块所属的更大的父块 (Parent Chunks)（例如，小块是句子，父块是包含该句子的段落）。
检索时，先用查询向量匹配小块。
一旦找到相关的小块，不直接将小块传递给 LLM，而是返回其对应的父块。

优点：结合了小块的检索精度和大块的上下文完整性。既能精准定位相关信息点，又能为 LLM 提供更丰富的背景。
缺点：需要维护小块和父块之间的映射关系，增加了索引和检索逻辑的复杂度。
适用场景：既需要高精度检索，又需要充分上下文来生成高质量答案的 RAG 应用。

命题分块

核心思想：尝试将文本分解为更小的、原子性的事实陈述或主张（Propositions） 。这通常需要借助 LLM 或专门的 NLP 模型来识别和提取文本中的核心命题。例如，句子“苹果公司在 2023 年发布了 Vision Pro 头显，定价 3499 美元”可能会被分解为：“苹果公司发布了 Vision Pro 头显”、“Vision Pro 头显发布于 2023 年”、“Vision Pro 头显定价 3499 美元”等命题。然后对这些命题进行索引和检索。
优点：产生了非常细粒度、高度聚焦的知识单元，非常适合进行精确的事实检索和问答。
缺点：
- 严重依赖 LLM 或 NLP 模型的抽取能力，可能产生错误或不完整的命题。
- 计算成本高昂，处理速度慢。
- 可能丢失原始文本的语气、复杂关系和细微差别。
- 如何将检索到的离散命题有效地组合起来提供给生成模型是一个挑战。
适用场景：知识库构建、事实性问答系统，对信息的原子性和精确性要求极高的场景。

Agentic / LLM-based Chunking

核心思想：更进一步，让一个智能体 (Agent) 或直接使用 LLM 来决策如何进行分块。可以给 LLM 设计特定的 Prompt，让它根据内容理解来判断最佳的分割点，或者让 Agent 动态地选择和组合不同的分块策略。
优点：潜力巨大，理论上可以实现最智能、最符合语义和上下文的分块。
缺点：
- 实现非常复杂，需要精巧的 Prompt Engineering 或 Agent 逻辑设计。
- 成本高（LLM 调用开销），速度慢。
- 结果的可控性和稳定性可能不如确定性算法。
- 仍处于探索阶段，成熟度和可靠性有待验证。
适用场景：研究探索性质的项目，或者对分块质量有极致追求且不计成本的特定应用。

块优化策略--上下文富化 (Context Enrichment)

核心思想：这不是一种独立的分割方法，而是在分块之后，为每个 Chunk 添加额外的上下文信息。例如，可以在每个 Chunk 前后添加其相邻的句子或摘要信息，或者添加该 Chunk 所属章节/段落的标题作为元数据（如 MarkdownHeaderTextSplitter 所做）。
优点：在不显著增大 Chunk 大小的情况下，为 LLM 提供更多线索，帮助其理解 Chunk 在原文中的位置和背景。
缺点：需要额外的处理步骤来提取和添加这些富化信息。
适用场景：可以与其他任何分块策略结合使用，作为一种优化手段，特别是在 Chunk 较小，担心上下文不足时。

Embedding

用于将离散的对象（如词语、图像、用户等）映射到一个连续的向量空间中，目的是捕捉对象之间的语义关系，将高维、稀疏的表示转化为低维、稠密的向量表示，从而便于模型的学习和计算。

在 NLP 中，Embedding 最广泛的应用是词嵌入。通过将单词映射为向量，模型可以更好地理解和处理文本数据。词嵌入能够捕捉到单词之间的语义关系，如相似性和类比关系。示例：词嵌入技术如 Word2Vec、GloVe 将单词映射为实数向量，这些向量可以在语言模型、文本分类、情感分析等任务中使用。

常见的Embedding方法;

Word2vec
Glove(Global vectors for represetation)
矩阵分解、Doc2vec、Deepwalk

优势与挑战：

优势：

降低维度： Embedding 能够将高维、稀疏的离散数据映射为低维、稠密的向量表示，便于模型学习和计算。
捕捉语义关系：通过 Embedding，模型能够捕捉对象之间的语义关系，如词语的相似性、类比关系等。
广泛应用： Embedding 在 NLP、推荐系统、计算机视觉等多个领域得到了广泛应用，并且已经成为深度学习中的基础技术。

挑战：

向量空间的解释性：虽然 Embedding 能够捕捉语义关系，但向量空间的具体维度往往缺乏明确的解释性。
训练复杂度：高质量的 Embedding 通常需要大量数据和计算资源，尤其是在训练深度模型时。
多义性问题：对于具有多种含义的词语，单一的词嵌入可能无法有效区分不同语义，这在某些情况下会导致模型的准确性下降。

RAG多路召回

RAG多路召回-CSDN博客

大模型应用架构实践进阶

LangChain开发实践

LangChain

它是一个开源框架，用于提升大语言模型功能，允许开发人员将大语言模型与外部的计算和数据源结合起来，目前，它提供了Python和JavaScript的软件包。

它通过三个核心组件实现增强；

首先是Compass“组件”，为LLMs提供接口封装、模板提示和信息检索索引。
其次是Chains“链”，它将不同的组件组合起来解决特定的任务，比如在大量文本中查找信息。
最后是Agents“代理”，它们使得LLMs能够与外部环境进行交互，例如通过API请求执行操作。

LangChain如何工作:

提问：用户提出问题。

向语言模型查询：问题被转换成向量表示，用于在向量数据库中进行相似性搜索。

获取相关信息：从向量数据库中提取相关信息块，并将其输入给语言模型。

生成答案或执行操作: 语言模型现在拥有了初始问题和相关信息，能够提供答案或执行操作。

Agent智能体架构

AutoGen

探秘AutoGen框架：从入门到实践的全攻略（25/30）-腾讯云开发者社区-腾讯云

向量空间的解释性：虽然 Embedding 能够捕捉语义关系，但向量空间的具体维度往往缺乏明确的解释性。训练复杂度：高质量的 Embedding 通常需要大量数据和计算资源，尤其是在训练深度模型时。多义性问题：对于具有多种含义的词语，单一的词嵌入可能无法有效区分不同语义，这在某些情况下会导致模型的准确性下降。

核心特性：

多代理对话: AutoGen 允许开发者创建多个自主代理，这些代理可以在一个对话环境中相互交流、协作，以完成复杂的任务。每个代理都有其独特的角色和功能，它们通过发送和接收消息来进行互动。例如，在一个数据分析项目中，可以创建一个数据收集代理，负责从各种数据源获取数据；一个数据分析代理，对收集到的数据进行分析和建模；以及一个报告生成代理，根据分析结果生成详细的报告。

简化工作流：该框架简化了 LLM 工作流的编排、自动化和优化过程。以往，开发者在使用 LLM 构建应用时，需要手动处理大量繁琐的流程，如模型调用、参数设置、对话管理等。而 AutoGen 通过提供一系列的工具和接口，将这些复杂的操作进行了封装和自动化处理。开发者只需关注业务逻辑和任务需求，通过简单的配置和代码编写，就可以实现高效的 LLM 应用开发。例如，在一个智能客服系统中，开发者可以利用 AutoGen 快速搭建起对话流程，使客服代理能够自动识别用户问题，并调用合适的模型进行回答，无需手动编写复杂的对话管理逻辑。这不仅减少了开发时间和工作量，还提高了应用的稳定性和可维护性。

模块化处理：AutoGen 采用模块化的架构设计，使得开发者可以轻松地创建自定义代理，并根据具体需求进行灵活组合。每个模块都具有独立的功能，如代理模块负责与其他代理进行对话和交互，模型模块负责提供语言模型支持，工具模块负责调用外部工具等。例如，在一个电商智能推荐系统中，开发者可以基于 AutoGen 的模块化设计，创建一个商品推荐代理，该代理可以结合用户行为数据、商品信息等，利用语言模型进行分析和推理，最终为用户提供个性化的商品推荐。同时，开发者还可以根据实际情况，对代理的功能进行扩展和优化，如增加实时数据更新功能、优化推荐算法等。

LLM统一网关：LiteLLM

LLM统一网关：LiteLLM 详细介绍（实践篇）前面一篇文件介绍了为什么要使用LiteLLM以及使用LiteLLM的两 - 掘金

为什么手搓Agent而不是用LangChain等框架

框架凭借其内置的成熟流程、标准化接口及生态整合能力，更适用于快速落地标准化业务、复杂多组件协作场景或作为学术研究中的可复现基准，而手搓Agent则因能穿透框架抽象层实现深度定制化逻辑、灵活适配垂直领域特殊需求或探索前沿架构，在需要掌控底层原理、突破框架限制的场景中更具优势，二者在工程实践中通过效率与灵活性的互补形成协同。

Agent和Workflow的区别

(99+ 封私信 / 84 条消息) AI Agent（智能体）和AI Workflow（工作流）到底有什么不同？ - 知乎

MCP

(99+ 封私信 / 84 条消息) MCP (Model Context Protocol)，一篇就够了。 - 知乎

重点看看与Function Call的对比

A2A

(99+ 封私信 / 84 条消息) A2A协议(Agent to Agent Protocol)详解与官方案例实践分享 - 知乎

ReACt FrameWork

(99+ 封私信 / 84 条消息) ReAct论文解读：LLM ReAct范式，在大语言模型中结合推理和动作 - 知乎

CoT

思维链 CoT：让大模型把一个问题拆解为多个步骤，一步步分析，模拟人类逐步思考的方式。

思维树 ToT：生成多条推理路径，形成一个树状结构。这允许在推理时探索不同的分支，类似于你在面对决策时考虑不同的选择。

思维图 GoT：不仅生成多条推理路径，而且这些路径可以交叉和重新连接，形成一个有向图网络。

为什么思维链，能提升大模型推理能力？

大模型在预测下一个字时，会考虑你输入的每个字与前面字的相关度，以及每个字与所有字的相关度。

当你需要较高准确度的结果时（特别是像数学题这种分毫不差的要求），应该明确提出你已知的信息和关键词。

这样，模型会增加这些关键词的权重，并沿着这个方向进行分析，从而提高答案的准确性。

不然，得到的都是很宽泛的答案。

怎么用思维链 CoT 呢？

思维链 CoT 的用法：在输入末尾加一句 — 请一步一步仔细思考，并写出你思考的过程。

缺点不过，CoT对模型性能的提升与模型的大小成正比关系，模型参数至少达到100亿才有效果，达到1000亿效果才明显，测试效果最好的是 5400亿参数的大模型。

研究中指出，处理策略性问题通常需要大量的世界知识。

然而，小型模型由于其有限的参数，往往难以存储这些庞大的知识信息，这限制了它们在产生正确推理步骤方面的能力。

思维链改进

CCoT 根据任务，限制长度，避免冗余输出，就能提升正确率
Auto-CoT：不用人工，让机器从各种问题中学习，生成多种多样的推理链

大模型微调和私有化部署

大模型学习

大模型核心原理

大模型提示工程

Prompt caching

大模型API应用开发工程

分词器tokenizer

Function Call

RAG

文档分割

Embedding

RAG多路召回

大模型应用架构实践进阶

LangChain开发实践

LangChain

Agent智能体架构

AutoGen

LLM统一网关：LiteLLM

为什么手搓Agent而不是用LangChain等框架

Agent和Workflow的区别

MCP

A2A

ReACt FrameWork

CoT

大模型微调和私有化部署

模型微调Fine-Tuning

大模型中 temperature、top_p、top_k

大模型幻觉

LoRA

微调和RAG的优劣势