MoreRSS

site iconAlan Hsu修改

博客 随笔
博客名：X·myLog，个人纪录向博客。
RSS: https://www.xmylog.com/rss/feed.xml
请复制 RSS 到你的阅读器，或快速订阅到 :

Inoreader Feedly Follow Feedbin Local Reader

Alan Hsu的 RSS 预览

评测Prompt

2025-01-19 08:00:00

📌
模型评测第一步也是使用模型进行推理，推理时Prompt质量影响模型的输出。因此在模型评测的时候，也非常重视Prompt的质量。
大量的实验表明，即便测试的原始题目相同，对于 prompt 的不同构造方式会对模型的表现产生影响。可能影响的因素包括：
  • Prompt 本身的构成方式，包括指令、in-context example、题目的写法；
  • in-context example 的选择，包括了选择的数量和方式；
  • 对 prompt 的使用方式。是让模型基于 prompt 进行补全，还是从候选的 prompt 中选择一个最好的作为答案？
通常使用两种Prompt策略：Few-short Prompt和COT Prompt。
notion image
通常，我们会在 prompt 开头放入指令，几个 in-context example（上下文样例），再在最后放入题目。例如：
 
 
 
 
 
 
 
🎒
离开乏味的皮囊，自由的灵魂在路上
  • Name: Alan Hsu
  • Tag: 随感、技术、经验、旅行、推荐、生活、音乐、电影 etc.
  • Email：xulanzhong521gmail.com
  • WeChat: Alan_Hsu_521
notion image
notion image
 
 
 

大模型评测指标

2025-01-19 08:00:00

📌
 
评测指标可以分为通用指标、任务特定指标和数据集特定指标。
  • 通用指标（Generic metrics）：可以应用于多种任务和数据集的指标，如评估有标签的（监督式）数据集的精确度（precision）和准确度（accuracy）这样的指标，以及用于评估生成任务（无监督）的困惑度（perplexity）指标。
  • 任务特定指标（Task-specific metrics）：这类指标限定于特定的任务。例如，机器翻译任务（Machine Translation）通常使用BLEU或ROUGE这样的指标进行评估，而命名实体识别（Named Entity Recognition）任务则常用seqeval指标进行评估。
  • 数据集特定指标（Dataset-specific metrics）：某些数据集，例如GLUE和SQuAD有与之相关的特定评估指标。

1. 通用指标

accuracy 准确率 https://huggingface.co/spaces/evaluate-metric/accuracy
Precision 精确度https://huggingface.co/spaces/evaluate-metric/precision
Recall召回率https://huggingface.co/spaces/evaluate-metric/recall
F1分数https://huggingface.co/spaces/evaluate-metric/f1
ROCAUC https://huggingface.co/spaces/evaluate-metric/roc\\_auc
困惑度（perplexity）https://huggingface.co/spaces/evaluate-metric/perplexity

2. 任务特定指标

BLEU指标应用场景、计算方法https://huggingface.co/spaces/evaluate-metric/bleu
ROUGE https://github.com/huggingface/evaluate/blob/v0.4.3/metrics/rouge/
GoogleBLEUhttps://huggingface.co/spaces/evaluate-metric/google\_bleu
MAUVE https://github.com/huggingface/evaluate/blob/main/metrics/mauve/
seqevalhttps://github.com/huggingface/evaluate/blob/main/metrics/seqeval/
CodeEvalhttps://huggingface.co/spaces/evaluate-metric/code\_eval

3. 数据集特定指标

GLEU https://github.com/huggingface/evaluate/tree/main/metrics/glue
SQuAD https://github.com/huggingface/evaluate/tree/main/metrics/squad

4. 选择合适的指标

参考https://huggingface.co/docs/evaluate/choosing\_a\_metric
在选择评估指标时，需要考虑任务的特定需求。下面是寻找和选择合适指标的方法。这些方法包括查看任务相关的资源、参考排行榜、阅读指标卡片以及查阅最新的研究文献。
  • 查看排行榜：你可以在像Papers With Code这样的网站上查看排行榜，这些网站允许你按任务和数据集进行搜索。在论文中，通常会有说明用到的评估指标。
  • 阅读指标卡片：你可以阅读相关指标的指标卡片，看看哪些指标适合你的用例。例如，可以查看BLEU指标卡片或SQuAD指标卡片。 或者查阅Github网站https://github.com/huggingface/evaluate/tree/main/metrics
  • 查阅论文和博客文章：还可以查看发表的相关论文和博客文章，了解它们报告了哪些指标。由于指标可能会随时间变化，因此尽量挑选近几年的论文。
 

选择合适的指标

https://huggingface.co/docs/evaluate/choosing\\_a\\_metric

Pass@K

论文地址：https://arxiv.org/abs/2107.03374
工具地址：https://huggingface.co/spaces/evaluate-metric/code_eval

研究论文

《Evaluating Large Language Models Trained on Code》介绍了HumanEval数据集的构建方法和评估标准，以及如何使用这个数据集来测试和比较不同代码生成模型的性能。

评估工具

CodeEval工具可以方便地使用HumanEval数据集来评估和比较不同代码生成模型的性能。使用方法：
注意：国内需要配置链接huggingface的代理，否则会得到下面的报错。
requests.exceptions.ConnectionError: HTTPSConnectionPool(host='huggingface.co', port=443): Max retries exceeded with url: /api/spaces?filter=measurement (Caused by NewConnectionError('\<urllib3.connection.HTTPSConnection object at 0x7feea0e84190>: Failed to establish a new connection: \[Errno 60] Operation timed out'))
如果没有代理服务器，则需要将相关的metric script下载到本地。打开https://github.com/huggingface/evaluate/，下载 metrics 文件夹，放在测试脚本的目录下，并将evaluate.load()的参数由’code\_eval' 改为 本地的目录’./metrics/code\_eval’
具体步骤如下：
  1. 加载评估工具：从 evaluate 库中加载 code_eval 评估工具。将会从huggingface下载，因此需要配置代理。
  1. 定义测试用例：指定一个或多个测试用例，用于验证候选代码片段的正确性。
  1. 定义候选代码：指定一个或多个候选代码片段，这些代码片段将被评估。
  1. 计算评估结果：调用 code_eval.compute 方法，传入测试用例和候选代码片段，计算 pass@k 评估结果。
  1. 打印评估结果：输出 pass@k 的评估结果，显示候选代码片段通过测试用例的情况。
code_eval.compute 方法的参数包括：
  • predictions：要评估的候选预测列表。每个候选预测应该是一个字符串列表，包含多个代码候选项。
  • references：每个预测对应的测试用例列表。每个测试应该评估一个代码候选项的正确性。
  • k：在评估中要考虑的代码候选项数量。默认值是\[1, 10, 100]。
  • num\_workers：用于评估候选程序的工作线程数（默认值是4）。
  • timeout：在被认为是“超时”之前，产生一个预测的最大时间。默认值是3.0（即3秒）。
注意：因为CodeEval工具会执行predictions中的代码，因此，强烈建议用户不要在没有强大安全沙箱的情况下这样做，避免带来安全风险。
\#############################################################################
!!!WARNING!!!
\#############################################################################
The "code\_eval" metric executes untrusted model-generated code in Python.
Although it is highly unlikely that model-generated code will do something
overtly malicious in response to this test suite, model-generated code may act
destructively due to a lack of model capability or alignment.
Users are strongly encouraged to sandbox this evaluation suite so that it
does not perform destructive actions on their host or network. For more
information on how OpenAI sandboxes its code, see the paper "Evaluating Large
Language Models Trained on Code" (https://arxiv.org/abs/2107.03374).
Once you have read this disclaimer and taken appropriate precautions,
set the environment variable HF\_ALLOW\_CODE\_EVAL="1". Within Python you can to this
with:
\>>> import os
\>>> os.environ\["HF\_ALLOW\_CODE\_EVAL"] = "1"
\#############################################################################
上面代码将会输出pass\_at\_k：{'pass@1': 0.5, 'pass@2': 1.0}，这是因为：
  • pass@1 为 0.5：这意味着在前 1 个候选代码片段中，只有 50% 的代码片段通过了测试用例。具体来说，def add(a, b): return a+b 通过了测试用例 assert add(2,3)==5，而 def add(a, b): return a*b 没有通过。
  • pass@2 为 1.0：这意味着在前 2 个候选代码片段中，有 100% 的代码片段通过了测试用例。具体来说，虽然 def add(a, b): return a*b 没有通过，但 def add(a, b): return a+b 通过了，所以整体上 100% 的候选代码片段通过了测试用例。
上面代码将会输出results：
 

F1

https://huggingface.co/spaces/evaluate-metric/f1
【机器学习】一文读懂准确率、精确率、召回率、F1分数、ROC-AUC都是什么\_机器学习\_十了个九-GitCode 开源社区
 

Bleu

https://huggingface.co/spaces/evaluate-metric/bleu
BLEU（Bilingual Evaluation Understudy）是一种用于评估机器将一种自然语言翻译成另一种自然语言后文本质量的算法。“机器翻译越接近专业人类翻译，质量就越好”。

BLEU的评分方式

  1. BLEU分数是针对单个翻译片段（通常是句子）计算的，通过将它们与一组高质量的参考翻译进行比较得出。
  1. 然后，这些分数在整个语料库上平均，以估计翻译的整体质量。
  1. BLEU不考虑可理解性或语法正确性。

网页版计算工具

可以用HuggingFace网站提供的网页版计算工具：https://huggingface.co/spaces/evaluate-metric/bleu
notion image
  1. 输入数据：
    • predictions：这是一个包含预测句子的列表，这些句子是机器翻译系统生成的。
    • references：这是一个包含参考译文列表的列表，每个预测句子可以对应多个参考译文。
    1. 输出结果：
      • bleu：BLEU分数，这是一个介于0和1之间的值，值越高表示翻译质量越好。
      • precisions：n-gram精确度的几何平均值，这是一个列表，包含了不同n-gram顺序下的精确度。
      • brevity_penalty：简洁性惩罚，用于处理预测句子比参考译文短的情况。
      • length_ratio：长度比，即预测句子长度与参考译文长度的比值。
      • translation_length：翻译长度，即预测句子的长度。
      • reference_length：参考长度，即参考句子的长度。

      用Evaluate包计算

      需要安装evaluate包。
      计算代码：
      📢注意：evaluate.load需要重huggingface下载脚本，所以一定要配置proxy，否则会连不上huggingface.co
      requests.exceptions.ConnectionError: HTTPSConnectionPool(host='huggingface.co', port=443): Max retries exceeded with url: /api/spaces?filter=measurement (Caused by NewConnectionError('\<urllib3.connection.HTTPSConnection object at 0x7feea0e84190>: Failed to establish a new connection: \[Errno 60] Operation timed out'))
      另外解决办法：
      将相关的metric script下载到本地。具体方法是打开https://github.com/huggingface/evaluate/，下载 metrics 文件夹，放在测试脚本的目录下，并将evaluate.load()的参数改为本地的测试脚本目录，例如’./metrics/bleu’
      1. 参数
      完整参数参考这里https://github.com/huggingface/evaluate/blob/main/metrics/bleu/bleu.py
      • tokenizer：用于标准化预测句子和参考句子的方法。默认是tokenizer_13a，这是一种相对简单的标记化方法，但等同于WMT（Workshop on Machine Translation）使用的mteval-v13a。可以替换为其他标记化方法，例如NLTK的word_tokenize()或Tokenizers库的预训练标记器。
      • max_order：计算BLEU分数时使用的最大n-gram顺序，默认为4。
      • smooth：是否应用Lin et al.2004平滑方法，默认为False。
      1. 输出：
      输出的BLEU分数计算结果，包括BLEU分数、精确度、简洁性惩罚、长度比、翻译长度和参考长度。
      • bleu(float)：BLEU得分是一个浮点数，表示翻译文本与参考文本的相似度。BLEU得分总是在0到1之间，0表示完全不相似，1表示完全相同。
      • precisions(list of float s)：n-gram精确度的几何平均值，这里n-gram指的是文本中的连续n个词的组合。
      • brevity\_penalty(float)：简短性惩罚，用于处理翻译文本比参考文本短的情况。
      • length\_ratio(float)：长度比，即翻译文本长度与参考文本长度的比值。
      • translation\_length(int)：翻译文本的长度，以词为单位。
      • reference\_length(int)：参考文本的长度，以词为单位。

      相关知识

      tokenizer的作用是什么

      Tokenizer的主要作用是将文本数据分解成基本的单元，这些单元可以是单词、子单词、字符或者更小的片段，以便机器学习模型能够处理和理解文本。以下是tokenizer的一些主要功能和目的：
      1. 文本分割：将整个文本字符串分割成更小的单元，如单词、短语或符号，这些单元称为tokens。
      1. 标准化：确保tokens的一致性，例如，将所有英文单词转换为小写，以消除大小写的差异。
      1. 去除噪声：删除文本中的无关字符，如标点符号、特殊字符或停用词（stop words），这些通常不携带对模型有用的信息。
      1. 词汇表构建：在训练数据上构建一个词汇表，这个词汇表包含了所有唯一的tokens，用于后续将文本映射到数值表示。
      1. 序列化：将文本转换为固定长度的序列，这对于某些模型（如循环神经网络）是必要的。
      1. 子词分割：在处理未知单词或词汇外（out-of-vocabulary, OOV）的单词时，tokenizer可以将它们分割成子词（subword）或字符，以提高模型的泛化能力。
      1. 支持多语言：在多语言环境中，tokenizer需要能够处理不同语言的特定规则和结构。
      1. 预处理：执行其他预处理步骤，如词干提取（stemming）和词形还原（lemmatization），这些步骤有助于进一步规范化tokens。
      1. 编码：将tokens转换为模型可以理解的数值表示，如one-hot编码或词嵌入（word embeddings）。
      1. 保持语义：尽管tokenizer将文本分割成更小的单元，但它需要确保这些单元能够尽可能地保留原始文本的语义信息。
      在自然语言处理（NLP）任务中，如文本分类、情感分析、机器翻译等，tokenizer是文本预处理的重要步骤，它直接影响到模型的性能和结果的准确性。不同的任务和模型可能需要不同类型的tokenizer，例如，基于字符的tokenizer、基于单词的tokenizer或基于子词的tokenizer。

      Tokenizer库是什么

      Tokenizers库（https://huggingface.co/docs/tokenizers/index）是由Hugging Face开发的一个用于文本分词（tokenization）的Python库。它提供了多种分词器的实现，特别注重性能和通用性。以下是Tokenizers库的一些主要特点和功能：
      1. 多种分词器：支持多种流行的预制分词器，包括BERT WordPiece和三种最常见的Byte Pair Encoding（BPE）版本。
      1. 性能：由于基于Rust语言实现，Tokenizers库在训练和分词上都非常快速。它能够在服务器的CPU上在不到20秒的时间内对GB级的文本进行分词。
      1. 易用性与灵活性：Tokenizers库易于使用，同时也非常灵活，可以满足研究和生产的需求。
      1. 预处理功能：支持所有预处理操作，包括截断（Truncate）、填充（Pad）以及添加模型所需的特殊标记（如开始标记、结束标记等）。
      1. 规范化与对齐跟踪：在规范化过程中，Tokenizers库会跟踪对齐信息，使得用户可以获取原始句子中对应于给定标记的部分。
      1. 训练新词汇表：用户可以使用Tokenizers库来训练新的词汇表，并使用这些词汇表进行分词。
      1. 保存和加载分词器：可以轻松地保存训练好的分词器到文件，并在需要时加载它们。
      1. 与Hugging Face Hub集成：Tokenizers库可以与Hugging Face Hub集成，方便地加载预训练的分词器。
      1. 支持自定义分词器：如果预制的分词器不能满足需求，用户可以构建自己的分词器，通过组合不同的组件来满足特定的需求。
      Tokenizers库通过提供这些功能，成为了NLP任务中文本预处理的重要工具，特别是在需要高性能和高效率处理大量文本数据的场景中。它与Hugging Face的Transformers库一起使用，可以为各种NLP模型提供强大的文本处理能力。

      NTLK是什么

      NLTK（Natural Language Toolkit）是一个用于自然语言处理（NLP）的开源Python库。它提供了一系列强大的工具和资源，帮助用户处理和分析人类语言数据。以下是NLTK的主要特点和功能：
      1. 功能丰富：
        • NLTK包含了多种文本处理功能，如分词、词性标注、命名实体识别、句法分析、情感分析等。
        • 提供了对多种语料库和词汇资源的访问，例如WordNet。
        1. 易于使用：
          • NLTK提供了简单易用的API，适合初学者和研究人员使用。
          • 包含大量的示例和教程，帮助用户快速上手。
          1. 多种语料库：
            • NLTK内置了超过50种语料库，用户可以直接使用这些语料库进行实验和研究。
            • 这些语料库涵盖了多种文本类型，如新闻、文学作品、社交媒体等。
            1. 教育和研究用途：
              • NLTK被广泛用于教学和研究，尤其是在计算语言学和自然语言处理领域。
              • 提供了关于语言处理任务的基本概念和理论背景的学习材料。
              1. 跨平台支持：
                • NLTK可以在Windows、Mac OS X和Linux等多个操作系统上运行。
                1. 社区驱动：
                  • NLTK是一个社区驱动的项目，用户可以参与开发和贡献代码。

                  常见应用

                  • 文本预处理：分词、去除停用词、词干提取等。
                  • 文本分析：词频统计、情感分析、主题建模等。
                  • 信息提取：从文本中提取特定信息，如人名、地名等。
                  • 机器学习：用于训练和评估自然语言处理模型。

                  示例代码

                  以下是一些使用NLTK的简单示例：
                  1. 分词：
                  1. 词性标注：
                  1. 命名实体识别：
                  NLTK是一个强大的工具，适合用于各种自然语言处理任务，是学习和研究NLP的理想选择。
                  计算BLEU分数时，使用NLTK的word_tokenize()作为分词器。

                  什么是Lin et al.2004平滑方法

                  Lin et al.2004平滑方法是Chin-Yew Lin和Franz Josef Och在2004年提出的用于计算BLEU分数时的一种平滑技术。这种平滑方法旨在解决机器翻译评估中的一个问题：当机器翻译输出中没有某个n-gram时，会导致该n-gram的精确度为零，从而可能对整体BLEU分数产生不利影响。Lin et al.2004平滑方法通过在计算中添加一个小的常数（epsilon），来避免零精确度的问题，使得BLEU分数更加稳定和可靠。
                  具体来说，Lin et al.2004平滑方法有两种主要的形式：
                  1. 方法1：在每个n-gram的精确度计算中，如果分母（即参考翻译中n-gram的数量）不为零而分子（即机器翻译输出中匹配的n-gram数量）为零时，就在分子上加上一个很小的常数epsilon。这样，即使没有匹配的n-gram，也能获得一个非零的精确度值，从而避免对BLEU分数产生过大的负面影响。
                  1. 方法2：在计算每个n-gram的精确度时，不仅在分子上加上一个小的常数，还在分母上加上同样的常数。这种方法受到Chin-Yew Lin和Franz Josef Och在2004年发表的论文"ORANGE: a Method for Evaluating Automatic Evaluation Metrics for Machine Translation"的影响。
                  这两种方法都旨在通过引入一个小的调整来平滑BLEU分数的计算，减少由于偶然缺少特定n-gram而导致的评分波动，使得评分结果更加稳定和可靠。

                  什么是n-gram

                  n-gram 是一种统计语言模型，用于预测文本中连续出现的项目（如字母、音节或单词）的概率。它基于这样的假设：一个项目的出现倾向于依赖于前面几个项目。n-gram 模型通过统计和利用这些连续项目的出现频率来预测下一个项目。
                  具体来说：
                  1. 1-gram（一元模型）：只考虑单个项目（如单词或字母）出现的频率，不考虑上下文。
                  1. 2-gram（二元模型）：考虑两个连续项目（如两个连续单词或字母）同时出现的概率。
                  1. 3-gram（三元模型）：考虑三个连续项目同时出现的概率，以此类推。
                  n-gram 模型中的 "n" 表示连续项目的数量。例如：
                  • 对于句子 "I have a dream"：
                    • 1-gram: I, have, a, dream
                    • 2-gram: (I, have), (have, a), (a, dream)
                    • 3-gram: (I, have, a), (have, a, dream)
                  n-gram 模型广泛应用于自然语言处理领域，包括：
                  1. 文本生成：根据已有的文本生成新的文本。
                  1. 语言模型评估：评估机器翻译、语音识别等系统的性能。
                  1. 信息检索：提高搜索引擎的准确性和相关性。
                  n-gram 模型的优点是简单、易于实现，但缺点是随着n的增加，模型需要处理的数据量呈指数级增长，可能导致数据稀疏问题。此外，n-gram 模型通常忽略了项目之间更长距离的依赖关系。尽管如此，n-gram 模型仍然是许多自然语言处理任务中的基础工具。

                  什么是数据稀疏问题

                  数据稀疏问题（Sparse Data Problem）是指在数据分析和机器学习中，由于数据量不足或者特征维度过高导致的数据中大部分值都是零或者缺失的现象。这种情况会给模型的训练和预测带来挑战，具体表现在以下几个方面：
                  1. 模型训练困难：当数据集中的大部分条目都是零或缺失时，模型可能无法有效地学习到数据中的模式和关系，因为有效的信息太少。
                  1. 过拟合风险：数据稀疏可能导致模型在有限的数据上过度拟合，即模型在训练数据上表现良好，但在未见过的测试数据上表现差。
                  1. 特征选择问题：在高维数据中，很多特征可能是不相关的或者冗余的，这使得特征选择变得困难。
                  1. 计算效率低下：稀疏数据可能导致计算效率降低，因为存储和处理大量的零值是不必要的。
                  1. 统计分析问题：在统计分析中，数据稀疏可能导致估计的参数不准确，因为样本量不足以支撑统计推断。
                  为了解决数据稀疏问题，可以采取以下几种策略：
                  • 数据增强：通过生成合成数据或者对现有数据进行变换来增加数据量。
                  • 特征工程：通过特征选择或特征提取减少维度，去除不相关的特征。
                  • 正则化：在模型训练中使用正则化技术，如L1或L2正则化，以减少过拟合的风险。
                  • 降维：使用主成分分析（PCA）或其他降维技术减少特征空间的维度。
                  • 迁移学习：利用预训练模型的知识，将其应用到数据稀疏的问题上。
                  • 集成学习：通过集成多个模型的预测来提高模型的稳定性和准确性。
                  • 使用稀疏表示：在模型和算法中直接利用稀疏表示，例如在神经网络中使用稀疏连接。
                  数据稀疏问题是机器学习和数据科学中常见的挑战，需要根据具体情况选择合适的方法来解决。

                  什么是简短性惩罚？

                  简短性惩罚（Brevity Penalty，简称BP）是BLEU评分系统中的一个重要组成部分，用于避免机器翻译系统通过生成过短的翻译来不正当地提高其BLEU得分。这种惩罚是必要的，因为如果机器翻译的输出比参考翻译短，那么它在n-gram匹配上的表现可能会更好，即使翻译的质量并不高。
                  简短性惩罚的计算公式如下：
                  notion image
                  • 当机器翻译输出的长度大于或等于参考翻译的长度时，简短性惩罚BP为1，这意味着不对得分进行惩罚。
                  • 当机器翻译输出的长度小于参考翻译的长度时，BP的值会小于1，这会降低BLEU得分，以反映翻译输出的简短性。
                  简而言之，简短性惩罚确保了BLEU评分系统能够更公正地评估机器翻译的质量，防止因翻译过短而获得不应有的高分。

                  相关论文

                  BLEU: a Method for Automatic Evaluation of Machine Translation
                  P02-1040.pdf
                   

                  recall

                  https://huggingface.co/spaces/evaluate-metric/recall
                   

                  precision

                  https://huggingface.co/spaces/evaluate-metric/precision
                   

                  accuracy

                  https://huggingface.co/spaces/evaluate-metric/accuracy
                   

                  roc_auc

                  https://huggingface.co/spaces/evaluate-metric/roc_auc
                   

                  ROUGE

                  https://github.com/huggingface/evaluate/blob/v0.4.3/metrics/rouge/README.md
                  ROUGE（Recall-Oriented Understudy for Gisting Evaluation）是一种广泛使用的评估自动文摘和机器翻译质量的指标，它通过比较自动生成的摘要或翻译与一组参考摘要（通常是人工生成的）之间的重叠度来评估质量。ROUGE 的不同变体（如 ROUGE-N、ROUGE-L、ROUGE-S 等）针对不同的评估需求和场景进行了优化，使得 ROUGE 成为一个灵活且强大的评估工具。
                  需要注意的是，ROUGE 是不区分大小写的，意味着大写字母和对应的小写字母被视为相同。

                  应用场景

                  以下是 ROUGE 的一些具体应用场景：
                  1. 自动文摘：
                  评估生成的摘要与原文的相关性和完整性。ROUGE 指标可以帮助确定自动文摘系统是否能够捕捉到原文的关键信息，并以简洁的方式表达出来。
                  1. 机器翻译：
                  比较机器翻译的输出与源语言原文的贴切程度，帮助提升翻译系统的性能。ROUGE 可以量化翻译结果与原文之间的相似度，尤其是在保持原文主旨和关键信息方面。
                  1. 文本生成：
                  在 AI 创作领域，ROUGE 可用于评估模型生成的文本质量。这包括但不限于聊天机器人的回复生成、内容创作等场景，以确保生成的文本与预期的输出具有较高的一致性。
                  1. 信息检索：
                  衡量搜索引擎的检索结果与用户的查询语句的相关性。ROUGE 可以帮助评估搜索引擎返回的结果是否与用户的查询意图高度相关。
                  1. 单文档摘要：
                  对于从单一文档中生成的摘要，ROUGE 可以评估摘要是否包含了文档中的关键信息，并且是否与文档内容保持一致。
                  1. 多文档摘要：
                  在处理多个文档并生成一个综合摘要的场景中，ROUGE 可以用来评估摘要是否综合了多个文档的关键信息，尤其是在去停用词条件下。
                  1. 短摘要评估：
                  对于短摘要，ROUGE 可以评估摘要是否简洁且有效地传达了主要信息。
                  ROUGE 的不同变体（如 ROUGE-N、ROUGE-L、ROUGE-S 等）针对不同的评估需求和场景进行了优化，使得 ROUGE 成为一个灵活且强大的评估工具。

                  使用 Evaluate 包计算

                  Evaluate 包的这个指标是基于 Google Research 对 ROUGE 的重新实现的一个包装器。Google Research 对 ROUGE 的重新实现在这里 https://github.com/google-research/google-research/tree/master/rouge。

                  最简模式

                  输入一组预测结果和一组参考值即可。
                  • predictions(list)：预测结果的列表，每个预测是一个由空格分隔的字符串。
                  • references(list or list[list])：每个预测的参考文本列表，或者每个预测有多个参考文本的列表，每个参考文本也是一个由空格分隔的字符串。
                  📢注意：evaluate.load 需要重 huggingface 下载脚本，所以一定要配置 proxy，否则会连不上 huggingface.co
                  requests.exceptions.ConnectionError: HTTPSConnectionPool(host='huggingface.co', port=443): Max retries exceeded with url: /api/spaces?filter=measurement (Caused by NewConnectionError('\<urllib3.connection.HTTPSConnection object at 0x7feea0e84190>: Failed to establish a new connection: \[Errno 60] Operation timed out'))
                  另外解决办法：
                  将相关的 metric script 下载到本地。具体方法是打开 https://github.com/huggingface/evaluate/，下载 metrics 文件夹，放在测试脚本的目录下，并将 evaluate.load（）的参数改为本地的测试脚本目录，例如’。/metrics/bleu’
                  结果会返回一个字典，包含了 rouge1、rouge2、rougeL 和 rougeLsum 四种不同的 rouge 分数。ROUGE 值范围为 0 到 1。

                  自定义分词器

                  还可以传递一个自定义的分词器，这对于非拉丁语系的语言尤其有用。
                  这里的“分词器”（tokenizer）是指一种将文本分割成单词、短语或其他有意义的部分的程序或函数。在处理自然语言时，分词是文本预处理的一个重要步骤。对于非拉丁语系的语言，比如中文、阿拉伯语等，由于它们的文字系统和语言结构与拉丁语系（如英语、西班牙语等）不同，因此可能需要特定的分词器来正确处理文本。自定义分词器可以针对这些语言的特点进行优化，以提高分词的准确性和效率。例如，使用中文的 jieba 分词器。

                  多个参考文本

                  rouge 评估器可以处理每个预测对应多个参考文本的情况。在这种情况下，references 是一个二维列表，每个子列表对应一个预测的多个参考文本。
                  compute 完整参数：https://github.com/huggingface/evaluate/blob/main/metrics/rouge/rouge.py
                  • rouge_types(list)：要计算的 ROUGE 类型列表，默认为['rouge1','rouge2','rougeL','rougeLsum']。
                    • "rouge1"：字词级别，基于 1-gram（单字）的评分。
                    • "rouge2"：字词级别，基于 2-gram（双字）的评分。
                    • "rougeL"：句子级别，\<font style="color:rgba（0， 0， 0， 0.85）；">ROUGE 计算两段文本之间的最长公共子序列（LCS），忽略换行符。\</font>
                    • "rougeLSum"：摘要级别，使用"\n"换行符分割文本。\<font style="color:rgba(0, 0, 0, 0.85);">ROUGE 会计算每对参考段落和候选锻炼之间的最长公共子序列（LCS），并且计算所谓的联合最长公共子序列（union-LCS）。\</font>
                  • use_aggregator(boolean)：默认为 True。
                    • 如果use_aggregator=False，输出是一个字典，每个 ROUGE 类型对应一个分数列表，每个句子对应一个分数。
                    • 如果use_aggregator=True，输出是一个字典，每个 ROUGE 类型对应一个聚合分数。
                  • use_stemmer(boolean)：如果为 True，则使用 Porter 词干提取器去除单词后缀，默认为 False。
                  举个例子，如果rouge_types=['rouge1', 'rouge2']且use_aggregator=False，输出将是：
                  这意味着对于rouge1类型，两个句子的评分分别是 0.6666 和 1.0；对于rouge2类型，两个句子的评分分别是 0.0 和 1.0。
                  当use_aggregator=True时，输出格式与上面不同，不再是列表，而是直接给出每个 ROUGE 类型的聚合分数。例如，如果rouge_types=['rouge1', 'rouge2']且use_aggregator=True，输出将是：
                  这意味着对于rouge1和rouge2类型，聚合后的评分都是 1.0。
                  最后，这段话还提到 ROUGE 值的范围是 0 到 1，其中 0 表示没有重叠，1 表示完全匹配。

                  相关资料

                  ROUGE 存在一些局限性

                  Schluter （2017）The limits of automatic summarisation according to ROUGE.pdf 对 ROUGE 评估指标在自动文摘中的局限性进行了深入讨论。
                  根据提供的文档内容，ROUGE（Recall-Oriented Understudy for Gisting Evaluation）作为自动文摘评估的常用指标，存在以下几点局限：
                  1. NP-hard 问题：文档提供了第一个证明，表明针对 ROUGE 优化的提取式文摘是 NP-hard 问题。这意味着在理论上，要达到完美的 ROUGE 分数在计算上是非常困难的。
                  1. 完美分数难以实现：文档指出，对于提取式文摘，理论上很难达到完美的 ROUGE 分数。即使在最佳情况下，贪婪算法和精确全局解码方法的表现在 ROUGE 指标上也是相似的。
                  1. 高质量数据集的 100%完美分数不可能：由于 ROUGE 指标是通过多个参考文摘的平均分数来避免偏见，除非参考文摘包含完全相同的 n-grams，否则不可能获得 100%的 ROUGE-n 分数。
                  1. 相对完美分数高度多样化且难以达到：ROUGE 分数通常对于短文摘较低，对于长文摘分数似乎更高，即使文档长度也大幅增加。文档指出，即使拥有参考文摘的句子，也不可能达到相对完美的分数，甚至人类也无法实现 ROUGE 所描述的最优文摘。
                  1. 最先进的自动文摘是无监督的：尽管在神经网络的帮助下，监督式文摘取得了一些进展，但由于数据规模的要求，这些系统仅限于标题生成系统，因此不在本文的讨论范围内。
                  1. 评估指标的上限问题：文档提出，对于自动文摘评估指标，存在一个上限问题，即没有自然的上限来界定文摘系统的质量，甚至人类也无法进行最优的文摘。
                  1. ROUGE 分数与人类评价的相关性：尽管之前的研究表明 ROUGE 分数与人类评价之间存在相关性，但这并没有解决上限问题。文档中提到，即使在参考文摘之间进行评估，ROUGE 分数也远低于最优性能，这表明人类作为抽象式文摘者，根据 ROUGE 的标准，其性能也是有限的。
                  这些局限指出了 ROUGE 作为评估自动文摘质量的指标时存在的问题，特别是在理论上的困难、完美分数的不可达性以及与人类评价的不一致性。

                  中文文本使用什么分词器？

                  对于中文文本处理，特别是 ROUGE 评估时，选择合适的分词器非常重要。以下是一些常用的中文分词器：
                  1. 结巴分词（jieba）
                    • 简介：结巴分词是一个流行的 Python 中文分词库，支持三种分词模式：精确模式、全模式和搜索引擎模式。它还支持用户自定义词典，并且可以进行词性标注和关键词提取。
                    • 特点：安装简单，功能丰富，社区活跃。
                    1. 清华大学 THULAC
                      • 简介：THULAC（THU Lexical Analyzer for Chinese）由清华大学自然语言处理与社会人文计算实验室研制，具有中文分词和词性标注功能。它集成了大规模的人工分词和词性标注中文语料库，模型标注能力强大。
                      • 特点：准确率高，速度快。
                      1. HanLP
                        • 简介：HanLP 是一个大规模的自然语言处理库，包含了丰富的中文处理功能，如分词、词性标注、命名实体识别等。
                        • 特点：功能全面，性能优良。
                        1. SnowNLP
                          • 简介：SnowNLP 是一个 Python 库，可以方便地处理中文文本内容，包括中文分词、词性标注、情感分析等功能。
                          • 特点：易于上手，功能实用。
                          1. PKUSeg（北京大学词法分析工具包）
                            • 简介：PKUSeg 是由北京大学语言计算与机器学习研究组开发的中文分词工具包，支持多种领域模型。
                            • 特点：领域适应性强。
                            1. FoolNLTK
                              • 简介：FoolNLTK 是一个使用双向 LSTM（BiLSTM）模型构建的中文处理工具包，支持中文分词、词性标注、命名实体识别等。
                              • 特点：准确率高，但可能速度较慢。
                              选择分词器时，需要根据具体需求和场景来决定。例如，如果需要高准确率和快速处理，THULAC 可能是一个好选择；如果需要一个功能全面且易于使用的库，HanLP 和 jieba 分词可能更适合。

                              相关论文

                              ROUGE A Package for Automatic Evaluation of Summaries.pdf
                               
                               
                               
                               
                               
                               
                              🎒
                              离开乏味的皮囊，自由的灵魂在路上
                              • Name: Alan Hsu
                              • Tag: 随感、技术、经验、旅行、推荐、生活、音乐、电影 etc.
                              • Email：xulanzhong521gmail.com
                              • WeChat: Alan_Hsu_521
                              notion image
                              notion image
                               
                               
                               

                              评测方法

                              2025-01-19 08:00:00

                              📌
                               
                              评测方法主要有人工评测、自动化评测两大类。

                              1. 自动化评测

                              对于封闭式问题，也就是有标准答案的问题，比较适合使用脚本自动完成模型评测，这是一种客观评测方法。例如：通过大模型进行电商评论分析，分析电商评论是正向还是负向的。
                              使用的语料：https://huggingface.co/datasets/t1annnnn/Chinese\\_sentimentAnalyze
                              大模型使用的Promp
                              将如下语料输入给大模型后，得出大模型的答案，并与标准的结果进行对比。
                              notion image
                              小技巧：让模型预测的输出是个json格式，方便提取结果。
                              获取Kimi大模型输出的代码：
                              得到大模型输出，并和语料中的lable进行合并，结果片段如下：
                              在这个场景中，基于输出的结果中的sentiment和label两个字段，可以通过计算准确率、召回率等指标评估大模型的能力。
                              由于大语言模型输出自由度较高，在评测阶段，我们需要对其输入和输出作一定的规范和设计，尽可能减少噪声输出在评测阶段的影响，才能对模型的能力有更加完整和客观的评价。
                              在客观评测的具体实践中，我们通常采用下列两种方式进行模型输出结果的评测：
                              • 判别式评测：该评测方式基于将问题与候选答案组合在一起，计算模型在所有组合上的困惑度（perplexity），并选择困惑度最小的答案作为模型的最终输出。例如，若模型在 问题? 答案1 上的困惑度为 0.1，在 问题? 答案2 上的困惑度为 0.2，最终我们会选择 答案1 作为模型的输出。
                              • 生成式评测：该评测方式主要用于生成类任务，如语言翻译、程序生成、逻辑分析题等。具体实践时，使用问题作为模型的原始输入，并留白答案区域待模型进行后续补全。我们通常还需要对其输出进行后处理，以保证输出满足数据集的要求。

                              2. 人工评测

                              针对开放式问题，通过制定规则进行人工打分是最靠谱的，这是一种主观评测方法。根据业务制定打分规则，根据规则进行人工打分。打分时，尽量屏蔽掉预测结果的来源，防止人为引入偏见。
                              评分标准制定：
                              以角色扮演大模型评估标准制定为例，评估的维度更看重人设遵循能力和回答质量。
                              • 人设遵循：言行是否符合角色设定的身份、特色和语气等。
                              • 场景符合：文风是否符合场景需求。
                              • 回答质量：回答是否与上下文对话相符，内容丰富、恰当。
                              计分方法有两类，打分方式有GSB打分和绝对分值：
                              • GSB（Good、Same、Bad）计分：用于评判针对同一评估集的两份预测结果之间的好坏。例如对比两个预测结果A和B，Good代表A比B好、Same代表两者质量相当，Bad代表A不如B。最后得到A和B的GSB打分比值。例如10:20:30，代表60条评估结果集中，有10条A比B好，20条A和B相当，30条A比B差。GSB适用于直接对比两个模型（或两组超参数）之间的好坏。
                              • 绝对分值：按照一定的评分标准直接对大模型进行结果评分。用于横向比较多个模型的效果。

                              3. 裁判员模型评测

                              A Survey on LLM-as-a-Judge
                              Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena
                              人工打分成本高昂，使用更强大的大模型对待评价大模型进行打分，即通过裁判员模型打分成为严重的一个重要课题。例如使用GPT-4作为裁判员评估其他模型的效果，从而降低人工打分成本。·
                              具体方法是：使用更强大的大模型作为裁判，对其他大模型的效果进行评分。例如使用GPT-4作为裁判，对Ernie speed和微调后的Ernie speed进行打分。裁判员模型的Prompt：
                              注意：为了确保评估结果有效性，自动打分结果也需要经过人工复查。
                              我们首先承认LLM评委可能存在的局限性:
                              • 位置偏见,LLM评委可能偏向比较中的第一个回答
                              • 冗长偏见,LLM评委可能偏向更长的回答,不考虑质量
                              • 自我增强偏见,LLM评委可能偏向自己的回答
                              • 有限的推理能力,指LLM评委在评判数学和推理问题时的可能缺陷
                              然后我们探索了如何通过少射判断、思路评判、基准评判和微调评判来缓解这些局限性。
                              在实施部分解决方案后,我们发现尽管存在局限性,强大的LLM评委如GPT-4可以与受控和众包的人类偏好实现非常好的一致性,达到80%以上的一致率。这一程度的一致性与两个不同人类评委之间的一致性相当。因此,如果谨慎使用,LLM评委可以作为人类偏好的一个可扩展和可解释的近似。
                               
                               
                               
                               
                               
                               
                              🎒
                              离开乏味的皮囊，自由的灵魂在路上
                              • Name: Alan Hsu
                              • Tag: 随感、技术、经验、旅行、推荐、生活、音乐、电影 etc.
                              • Email：xulanzhong521gmail.com
                              • WeChat: Alan_Hsu_521
                              notion image
                              notion image
                               
                               
                               

                              OpenCompass评测框架

                              2025-01-19 08:00:00

                              📌
                               
                              https://opencompass.org.cn/home
                              OpenCompass 由 上海人工智能实验室 研发的开源、高效、全面的大模型评测体系及开放平台。作为大模型标准测试工具被Meta AI官方推荐，点击 Llama 的 Standard Evaluation tools 获取更多信息。在魔塔社区上，司南评测功能，就是基于OpenCompass的实现。
                              截止2024年7月，OpenCompass支持语言理解、知识准确度、逻辑推理、创意生成、数学解题、代码编写、长篇文本处理及智能体交互等8大能力，29项核心任务的评测，评测集实际超过100个。
                              notion image
                              8大重点通用能力
                              29项核心任务
                              100+评测数据集
                              语言理解
                              信息抽取、意图识别、情感分析、内容总结、内容评价、多语言翻译、中华传统文化理解、中文语义理解、多轮对话
                              ㅤ
                              知识准确度
                              生活常识、自然科学(理科)、自然科学(工科)、社会科学、人文科学
                              ㅤ
                              逻辑推理
                              逻辑推理、常识推理
                              ㅤ
                              创意生成
                              内容扩写、内容续写、内容改写
                              ㅤ
                              数学解题
                              初等数学、中等数学、高等数学
                              ㅤ
                              代码编写
                              代码生成、代码分析
                              ㅤ
                              长文本处理
                              长文本理解与推理、长文本创作
                              ㅤ
                              智能体交互
                              任务规划、工具调用、反思能力、任务执行总结、多轮交互
                              ㅤ
                              除了以上这些，OpenCompass还基于 VLMEvalKit 开源评测框架，以纯生成类的方式评估多模态大模型在数十个开源评测集上的综合表现。
                              OpenCompass由三大组件组成，分别是评测工具CompassKit和VLMEvalKit、评测集社区CompassHub、评测榜单CompassRank。
                              • 评测工具CompassKit，以开源工具库的形式提供丰富的评测集和模型模板，支持灵活扩展，以满足各种模型评测实际业务需求。
                              • 评测工具VLMEvalKit，一个全新的开源多模态评测框架，旨在提供可靠、可复现的评测结果，助力社区更准确地比较不同多模态模型在各种任务上的性能。
                              • 评测集社区CompassHub，在社区内发布和分享评测集，包括了学科类、语言类、知识类、代码、数学、创作等多种任务类型的评测集。
                              • 评测榜单CompassRank，基于司南 OpenCompass 官方评测规则，对行业领先大模型进行评测，根据评测结果发布榜单

                              1. 工具架构

                              https://lmarena.ai/ https://modelscope.cn/studios/opencompass/CompassArena/summary?fullScreen=1
                              notion image
                              • 模型层：大模型评测所涉及的主要模型种类，OpenCompass以基座模型和对话模型作为重点评测对象。
                                • 基座模型：一般是经过海量的文本数据以自监督学习的方式进行训练获得的模型（如OpenAI的GPT-3，Meta的LLaMA），往往具有强大的文字续写能力。
                                • 对话模型：一般是在的基座模型的基础上，经过指令微调或人类偏好对齐获得的模型（如OpenAI的ChatGPT、上海人工智能实验室的书生·浦语），能理解人类指令，具有较强的对话能力。
                              • 能力层：OpenCompass从通用能力和特色能力两个方面来进行评测维度设计。在模型通用能力方面，从语言、知识、理解、推理、安全等多个能力维度进行评测。在特色能力方面，从长文本、代码、工具、知识增强等维度进行评测。
                              • 方法层：OpenCompass采用客观评测与主观评测两种评测方式。客观评测能便捷地评估模型在具有确定答案（如选择，填空，封闭式问答等）的任务上的能力，主观评测能评估用户对模型回复的真实满意度，OpenCompass采用基于模型辅助的主观评测和基于人类反馈的主观评测两种方式。
                              • 工具层：支持自动化地开展大语言模型的高效评测。包括分布式评测技术，提示词工程，对接评测数据库，评测榜单发布，评测报告生成等诸多功能。

                              2. 评估指标

                              目前 OpenCompass 中，常用的 Evaluator 主要放在 opencompass/openicl/icl_evaluator文件夹下， 还有部分数据集特有指标的放在 opencompass/datasets 的部分文件中，具体参考这里。
                              评估标准配置一般放在数据集配置文件中，即 xxdataset\_eval\_cfg 的evaluator参数。

                              3. 评测流程

                              在 OpenCompass 中评估一个模型通常包括以下几个阶段：配置 -> 推理 -> 评估 -> 可视化。
                              notion image
                              配置：这是整个工作流的起点。您需要配置整个评估过程，选择要评估的模型和数据集。此外，还可以选择评估策略、计算后端等，并定义显示结果的方式。
                              推理与评估：在这个阶段，OpenCompass 将会开始对模型和数据集进行并行推理和评估。推理阶段主要是让模型从数据集产生输出，而评估阶段则是衡量这些输出与标准答案的匹配程度。这两个过程会被拆分为多个同时运行的“任务”以提高效率，但请注意，如果计算资源有限，需要调整 --max-partition-size 的设置。
                              可视化：评估完成后，OpenCompass 将结果整理成易读的表格，并将其保存为 CSV 和 TXT 文件。你也可以激活飞书状态上报功能，此后可以在飞书客户端中及时获得评测状态报告。

                              4. 准备评测环境

                              需要先安装conda：
                              M1 mac安装conda：
                              https://github.com/conda-forge/miniforge/?tab=readme-ov-file#download
                              安装面向开源模型的GPU环境：
                              或者，安装面向API模型的CPU环境：
                              安装 OpenCompass
                              如果需要评测API模型，请 pip install -r requirements/api.txt 安装API模型的相关依赖。

                              5. 准备评测集

                              OpenCompass 支持的数据集主要包括三个部分：
                              1. Huggingface 数据集： Huggingface Dataset 提供了大量的数据集，这部分数据集运行时会自动下载。
                              1. ModelScope 数据集：ModelScope OpenCompass Dataset 支持从 ModelScope 自动下载数据集，需要设置环境变量：export DATASET_SOURCE=ModelScope。
                              1. OpenCompass 还提供了一些第三方数据集及自建中文数据集。在 OpenCompass 项目根目录下运行下面命令，将数据集准备至 ${OpenCompass}/data 目录下：
                              如果需要使用 OpenCompass 提供的更加完整的数据集 (\~1.79G)，可以使用下述命令进行下载和解压：
                              configs/datasets 目录下的结构，如下所示：
                              数据集配置文件名由以下命名方式构成 {数据集名称}_{评测方式}_{prompt版本号}.py。configs/datasets/ceval/ceval_gen_2daf24.py为例，配置文件则为全面的中文基础模型评估套件的 C-Eval 数据集，对应的评测方式为 gen，即生成式评测，对应的prompt版本号为 2daf24；
                              同样的， ceval_ppl_1cd8bf.py指评测方式为ppl即判别式评测，prompt版本号为 1cd8bf 。
                              除此之外，不带版本号的文件，例如： ceval_gen.py 则指向该评测方式最新的prompt配置文件，通常来说会是精度最高的prompt。
                              以 PIQA 数据集配置文件configs/datasets/piqa/piqa_gen_1194eb.py为示例，展示数据集配置文件中各个字段的含义。

                              6. 评测开源模型

                              OpenCompass 初体验，新手如何跑通第一个模型评测-CSDN博客
                              对于开源模型，OpenCompass 默认直接使用 HuggingFace model ID 从 hf 上下载开源模型和权重，对于一些无法访问外网的机器，这里很容易网络连接失败。这种情况下，可以先通过 ModelScope 下载待评测的模型。
                              这里以基座模型 InternLM2-1.8B 和对话模型 Qwen2-1.5B-Instruct 在 GSM8K 数据集上的评估为例。
                              1. 基座模型 InternLM2-1.8B 在 GSM8K 数据集上进行评估
                              从huggingface下载模型：
                              或者从 ModelScope 下载模型：
                              修改模型配置文件configs/models/hf_internlm/hf_internlm2_1_8b.py
                              将 path 替换为本地模型目录即可。并设置 tokenizer\_path 和path参数一样。
                              创建评估文件configs/eval_internlm2_1_8b.py，其中设置好datasets和models：
                              运行评估：
                              更多参数参考这里。从输出看internlm2-1.8b模型在gsm8k数据集的得分为29.80分，最终的评测结果会保存在 outputs/default/下面：
                              要想同时评估多个数据集，则可以在read_base同时导入多个数据集，并通过+将多个数据集拼接起来传给datasets参数。同理要想同时评估多个模型，也是在read_base同时导入多个模型，并通过+将多个模型拼接起来传给models参数。
                              可能得报错Error: mkl-service + Intel(R) MKL: MKL\_THREADING\_LAYER=INTEL is incompatible with libgomp.so.1 library.
                              解决办法：https://stackoverflow.com/questions/66932956/python-mkl-threading-layer-intel-is-incompatible-with-libgomp-so-1-library pip install -U numpy==1.25
                              下载模型
                              修改模型配置文件configs/models/qwen/hf_qwen2_1_5b_instruct.py
                              创建评估文件configs/eval_qwen2_1_5b_instruct.py，其中设置好datasets和models：
                              demo_gsm8k_chat_gen的内容：
                              demo_math_chat_gen的内容
                              执行评测python run.py configs/eval_qwen2_1_5b_instruct.py --debug，输出：

                              7. 评测基于API的模型

                              OpenCompass内置支持的API大模型可以从这里看到。OpenCompass将支持的API模型在opencompass.models进行了封装了。
                              这里以评估qwen大模型API为例，学习如何使用opencompass调用模型API进行评测。QWen的API已经封装在了opencompass/models/qwen_api.py里面，我们只需要配置QWen API评测文件configs/api_examples/eval_api_qwen.py即可，修改其中如下参数：
                              • path表示的是qwen系列大模型的名称。
                              • key是调用qwen大模型API的api-key。
                              • datasets配置评测数据集。
                              • work_dir 配置推理和评估的结果存储路径。
                              然后执行评估命令：
                              在正常模式下，评估任务将在后台执行。
                              • -mode all：指定任务的特定阶段。
                              评测进行大概执行了1个小时10分钟，其中推理花了1个半小时，评估花了10分钟。花了我40块钱\~\~\~。
                              推理过程的输出：
                              评估过程的输出：
                              评估之后的输出为：
                              评估结果保存至configs/api_examples/eval_api_qwen.py配置的work_dir里面。结构如下：
                              如果在 {WORKDIR} 中已经有模型输出，则指定为 eval 仅运行评测，获得评测结果；如果在 results/ 中已有单项评测结果，则指定为 viz 仅运行可视化；
                              • r: 重用已有的推理结果。如果后面跟有时间戳，则会复用工作路径下该时间戳的结果；否则则复用指定工作路径下的最新结果。

                              8. 评测自定义API模型

                              参考：：https://mp.weixin.qq.com/s/rpvV0PeHVueiPITVCIzJjg
                              目前OpenCompass已经支持的模型有 HF 模型、部分模型 API 、部分第三方模型。如果想支持更多的模型需要自定义扩展，OpenCompass提供了两种自定义的方式：
                              • 新增API模型
                              • 新增开源模型
                              NIOGPT平台作为蔚来大模型服务平台，上面部署了很多大模型，并通过API的方式对外提供服务。我们这里就以新增NIOGPT平台上的API模型为例，看下如何对OpenCompass进行扩展。
                              根据NIOGPT平台的接口定义，调用NIOGPT模型的方法如下：
                              第一步，根据上述方法定义API模型opencompass/models/niogpt_api.py，这一步我们可以参考OpenCompass已经支持的API模型，例如参考opencompass/models/qwen_api.py文件。继承 BaseAPIModel，并实现 generate 方法来进行推理，推理方法参考askChatGPTAgent。
                              同时修改opencompass/models/__init__.py，在文件中增加刚刚新增的NIOGPT的导出，新增代码如下：
                              这样一个自定义的API模型就完成了。
                              第二步，定义配置文件，在configs/api_examples目录下新建eval\_api\_niogpt.py，文件内容如下：
                              在配置文件中，我们可以设置它的测试集datasets，models的path参数设置相应的大模型名称，key参数设置成大模型调用的API的API-KEY，同时还可以通过work\_dir来设置测试结果输出的目录。
                              这样，在项目根目录下执行如下命令就可以开始评测了：
                              当query\_per\_second=1时，评测：100%|██████████| 165/165 \[36:38<00:00, 13.32s/it]
                              当query\_per\_second=2时，评测：100%|██████████| 165/165 \[29:04<00:00, 10.57s/it]

                              9. 基于LLM的主观评测

                              前面主要介绍了大模型的客观评测，但是客观评测面临以下几个重要问题：
                              • 题型固化，以选择题、填空题为主，与模型的真实应用场景有差异；
                              • 评测使用的测试集会可能被下一代模型的预训练或者微调，导致客观评测失真
                              • 各数据集的数据分布相对固定，导致结果和排名的差异
                              • 中心化的评测导致评测结果的透明度、可信度相对较低
                              为了解决客观评测的这些问题，主观评测具有以下优点：
                              • 评测数据形式多样
                              • 评测数据来自真实用户
                              • 评测是分布式的，评测结果相对可信
                               
                              notion image
                              流行的评估方法主要有:
                              • Compare模式：将模型的回答进行两两比较，以计算对战其胜率。
                              • Score模式：针对单模型的回答进行打分（例如：Chatbot Arena）。
                              主观评测旨在评估模型在符合人类偏好的能力上的表现。这种评估的黄金准则是人类喜好，但标注成本很高。
                              为了探究模型的主观能力，OpenCompass采用了JudgeLLM作为人类评估者的替代品（LLM-as-a-Judge）。基于以上方法支持了JudgeLLM用于模型的主观能力评估。
                              主观评测的具体流程包括:
                              1. 评测数据集准备
                              1. 使用API模型或者开源模型进行问题答案的推理
                              1. 使用选定的评价模型(JudgeLLM)对模型输出进行评估
                              1. 对评价模型返回的预测结果进行解析并计算数值指标
                              类似于已有的客观评测方式，可以在configs/eval_subjective.py中进行相关配置。
                              第一步，配置数据集，目前默认支持的数据集有：
                              第二步，设置待评测模型，需要设置do_sample的方式进行推理而不是greedy。
                              这里介绍一下do_sample和greedy两种不同的解码或生成策略：
                              1. Greedy Decoding（贪婪解码）:
                                • 在贪婪解码中，模型在每个时间步都会选择概率最高的输出。换句话说，它在生成序列时总是选择当前最有可能的下一个元素。
                                • 这种方法简单且计算效率高，但可能会导致结果缺乏多样性，有时也可能会陷入局部最优，而不是全局最优。
                                1. Sampling（采样）:
                                  • 采样是一种更灵活的生成策略，它在每个时间步都会根据概率分布进行随机选择。"do\_sample"通常是一个参数，当设置为True时，指示模型使用采样方法进行生成。
                                  • 采样可以增加结果的多样性，有时能够避免贪婪解码中的一些问题，如生成过于单调或重复的模式。
                                  • 采样方法通常包括：
                                    • 均匀采样：从概率分布中均匀地选择下一个元素。
                                    • 类别采样：根据类别的概率分布进行采样，常用于处理类别不平衡的数据集。
                                    • Top-k采样：只考虑概率最高的k个元素进行采样。
                                    • Top-p采样（Nucleus Sampling）：从累积概率超过某个阈值p的最小集合中采样，这个集合称为核（nucleus）。
                                  在进行主观评测时，可能需要模型生成更多样化和创造性的结果，因此使用采样方法而不是贪婪解码。而在客观评测中，可能会使用贪婪解码，因为它生成的结果是确定性的，便于评估和比较。
                                  例如，在自然语言处理中，使用采样方法可以生成更自然、更少重复的文本；而在机器翻译或文本摘要任务中，贪婪解码可能会生成更流畅但可能缺乏创造性的文本。
                                  第三步，配置judgemodel，通常被设置为GPT4等强力模型，可以直接按照config文件中的配置填入自己的API key，或使用自定义的模型作为judgemodel
                                  除了基本参数以外，还可以在config中修改infer和eval字段里的partitioner，从而设置更合适的分片方式，目前支持的分片方式主要有三种：NaivePartitoner, SizePartitioner和NumberWorkPartitioner 以及可以指定自己的workdir用以保存相关文件。
                                  最后，启动评测
                                  自定义主观评测集
                                  https://opencompass.readthedocs.io/zh-cn/latest/advanced\\_guides/subjective\\_evaluation.html#id7

                                  10. 支持新数据集

                                  1. 在 opencompass/datasets 文件夹新增数据集脚本 mydataset.py, 该脚本需要包含：数据集及其加载方式，需要定义一个 MyDataset 类，实现数据集加载方法 load，该方法为静态方法，需要返回 datasets.Dataset 类型的数据。参考：opencompass/datasets/ceval.py
                                  1. （可选）定义评测器类 MyDatasetlEvaluator ，实现评分方法 score，需要根据输入的 predictions 和 references 列表，得到需要的字典。参考opencompass/openicl/icl_evaluator/。
                                  1. （可选）定义后处理方法 mydataset_postprocess 方法，根据输入的字符串得到相应后处理的结果。
                                  1. 配置文件中应用自定义数据集、评估器和数据后处理方法。参考configs/datasets/ceval/ceval_gen_5f30c7.py

                                  11. 探究评测提示词

                                  在 OpenCompass 中，数据集需要转换为一系列的提示词输入给大模型，这个过程是由模板 (template) 来定义的。 template 拆分为两部分：数据侧的 template 和模型侧的 template。在测评模型时，数据会先后经过数据和模型侧的 template，最终转化为模型所需的输入。
                                  数据侧的 template 被称为 prompt\_template，它表示了把数据集的字段转化成提示词的过程。
                                  模型侧的 template 被称为 meta\_template，它表示了模型将这些提示词转化为自身期望的输入的过程。
                                  我们另外还提供了一些 思维链 的 prompt 示例。
                                  1. Prompt构建策略
                                  OpenCompass 将 prompt 的构建策略定义在了数据集配置中的 infer_cfg 部分。以configs/datasets/mmlu/mmlu_gen_4d595a.py中的mmlu_infer_cfg为例，如下所示：
                                  运行时，花括号{}内的字段会被替换成数据样本内的对应字段。如果数据样本中没有对应的字段，则会保持原样输出。
                                  在 OpenCompass 中，对于 0-shot 的评测，我们通常只需要定义 prompt_template 字段，即可完成 prompt 的构造。但对于 few shot 的评测，我们还需要定义 ice_template 字段，管理上下文学习中样例所对应的 prompt 模板。
                                  • Prompt模板
                                  mmlu\_infer\_cfg是对话式模板，其中prompt 是以不同角色 role 的对话为形式进行组织的。在当前 OpenCompass 的预定义数据集配置中，一个 prompt 中常有的角色有：
                                  • HUMAN：人类，通常为提问的一方
                                  • BOT：语言模型，通常为回答的一方
                                  • SYSTEM：系统，通常用在提示词的开头，负责下达指令。
                                  对话式模板更加灵活（相对于字符串模板），它可以结合模型侧不同的 meta\_template 生成不同对话形式的提示词，同时适用于基座和对话模型。更多的对话式模板的例子可以参考这里。
                                  • 推理方式不同Prompt模板不同
                                  OpenCompass 中主要支持了两种 Infernecer：GenInferencer 和 PPLInferencer，它们对应着两种不同的推理方式。
                                  GenInferencer 对应生成式的推理。在推理时，模型被要求以输入的提示词为基准，继续往下续写。此时，template 则单一地表示这一句话对应的模板，例如：configs/datasets/gsm8k/gsm8k_gen_1d7fe4.py
                                  而 PPLInferencer 对应判别式推理。在推理时，模型被要求计算多个输入字符串各自的混淆度 (PerPLexity / ppl)，并将其中 ppl 最小的项作为模型的推理结果。此时 template 是一个 dict，表示每一句话所对应的模板，例如configs/datasets/ceval/ceval_ppl_1cd8bf.py
                                  此时模型的推理结果将会是 template 的四个 key 之一 (“A” / “B” / “C” / “D”)
                                  • Meta Template
                                  Meta Template 与模型的配置相绑定，在运行时与数据集的对话式模板相结合，最终产生最适合当前模型的 prompt。
                                  下图展示了在语言模型上，数据从数据集中经过 prompt template 和 meta template，最终构建出 prompt 的几种情况。
                                  在对话开始或结束时嵌入其它字符串，如系统指令，可以在meta\_template中通过指定 begin 和 end 参数指定这些字符串。
                                  如果数据集中引入 SYSTEM 级别的角色，且模型同样接受 SYSTEM 这个角色，可以把 SYSTEM 角色的定义放进 meta\_template的reserved_roles 中。
                                  meta\_template 是一个字典，该字典可以包含以下数个字段：
                                  • begin，end ：(str，可选) prompt 的开头和结尾，通常是一些系统级别的指令。
                                  • round：(list) 每一轮对话的模板格式。每轮对话的 prompt 内容由数据集配置的对话式模板控制。
                                  • reserved_roles:（list，可选）指定 round 中并未出现，但有可能在数据集配置中用到的的预留角色，例如 SYSTEM 角色。
                                  • eos_token_id:（int, 可选）：指定了该模型的 eos token 的 id。如果不设置，则默认为 tokenizer 中的 eos token id。它的主要作用是在生成式任务中，截取模型的输出结果，因此一般应该被设置为 generate=True 的项所对应的 end 的第一个 token id。
                                  meta\_template 的 round 指定了一轮对话中每个角色说话的格式，接受一个字典组成的列表，每个字典的关键字如下：
                                  • role（str）: 参与对话的角色名，该字符串并不影响实际的 prompt。
                                  • begin, end (str): 指定该角色在说话时的固定开头或结尾。
                                  • prompt (str)：角色的 prompt。在 meta template 中允许留空，但此时必须在数据集配置的 prompt 中指定。
                                  • generate (bool): 指定为 True 时，该角色即为模型扮演的角色。在生成任务中，模型接收到的 prompt 会截止到该角色的 begin 处，剩下的内容由模型补全。
                                  在某些情况下（例如对基座的测试），我们并不需要在正常对话中注入任何的指令，此时我们可以将 meta template 置空。在这种情况下，模型接收到的 prompt 仅由数据集配置定义，是一个普通的字符串。若数据集配置使用的是对话式模板，不同角色的发言将会由 \n 拼接而成。
                                  API 模型的 meta template 与普通模型的 meta template 类似，但配置更为简单。用户可以根据情况，直接使用下面的两种配置之一，即可以多轮对话的方式评测 API 模型：
                                  下图展示了 API 模型接受的输入与 Prompt Template 、Meta Template 之间的关系。 OpenCompass 为 API 模型预设了三个 api_role：HUMAN, BOT, SYSTEM，API 模型会将对话重新以多轮对话格式打包，发送至后端。但要激活此功能，需要用户使用上面的 meta template 中把数据集 prompt 模板中的角色 role 映射到对应的 api_role 中。
                                  如果需要调试 prompt，建议在准备好配置文件后，使用 tools/prompt_viewer.py 脚本预览模型实际接收到的 prompt。

                                  12. 视频课程

                                  "https://player.bilibili.com/player.html?bvid=1Gg4y1U7uc&vd_source=7afb44332c571a8a5bfa5acec59995b0"
                                  "https://player.bilibili.com/player.html?bvid=1B142117hU&spm_id_from=333.337.search-card.all.click&vd_source=7afb44332c571a8a5bfa5acec59995b0"
                                   
                                   
                                   
                                   
                                   
                                   
                                  🎒
                                  离开乏味的皮囊，自由的灵魂在路上
                                  • Name: Alan Hsu
                                  • Tag: 随感、技术、经验、旅行、推荐、生活、音乐、电影 etc.
                                  • Email：xulanzhong521gmail.com
                                  • WeChat: Alan_Hsu_521
                                  notion image
                                  notion image
                                   
                                   
                                   

                                  AI应用评测工具

                                  2025-01-19 08:00:00

                                  📌
                                  一文梳理有效提升RAG效果的方法

                                  1. Ragas

                                  2. TruLens

                                  评估 RAG 的神器来啦！TruLens + Milvus=？TruLens 是一个用于评估语言模型应用(如 RAG)的性能的开源库。
                                  如何评估 RAG 应用的质量？最典型的方法论和评估工具都在这里了
                                  https://generativeai.pub/evaluating-rag-applications-with-trulens-9fad3bf352b6【trulens评估llamaindex构建的RAG】

                                  3. LlamaIndex

                                  评估 RAG？只要 LlamaIndex 就足够了 LlamaIndex 内置了评估工具，可以帮助你快速评估 RAG 应用
                                  evalscope， Ragas等框架，提供一套完整的多模态RAG评估实践指南，协助开发者全面评估图文多模态RAG流程。
                                  Retrieve算法评估
                                  https://docs.llamaindex.ai/en/stable/module\\_guides/evaluating/usage\\_pattern\\_retrieval.html
                                  Rerank算法评估
                                  Response评估
                                  https://docs.llamaindex.ai/en/stable/module\\_guides/evaluating/usage\\_pattern/

                                  4. Trulens-Eval

                                  如何评估 RAG 应用的质量？最典型的方法论和评估工具都在这里了

                                  5. DeepEval

                                  （https://github.com/confident-ai/deepeval）&#x20;
                                  https://mp.weixin.qq.com/s/FKdtrLBOTRQx-PSdZF4ZLQ

                                  6. Phoenix

                                  （https://docs.arize.com/phoenix/）有许多评估 LLM 的功能，比如评估 Embedding 效果、评估 LLM 本身。在评估 RAG 这个能力上，也留出接口

                                  7. LangSmith

                                  • 如何使用LangSmith进行评估
                                  还在困惑RAG评估？一篇文章彻底解析RAG评估工作流程！Langsmith
                                   
                                   

                                  Trulens

                                  https://www.trulens.org/
                                  TruLens 1.0 是一款用于评估和跟踪基于大型语言模型（LLM）应用的软件工具。它通过反馈函数客观衡量应用的质量和效果，帮助开发者快速迭代和选择最佳应用。TruLens 支持多种用例，如问答、摘要、检索增强生成和基于代理的应用。其反馈函数涵盖上下文相关性、安全性等多个维度，能够与任何基于 Python 的 LLM 应用兼容，助力开发者在成本、延迟和响应质量之间做出明智的权衡。
                                  • 核心功能与优势
                                    • 快速集成与使用: TruLens 可以轻松集成到 LLM 应用开发流程中，只需通过 pip 安装并添加几行代码即可开始使用。它能够跟踪任何应用，并使用开发者选择的模型进行评估，极大地简化了验证 LLM 应用的过程.
                                    • 高效迭代与反馈: 与传统的人工反馈相比，TruLens 提供的程序化反馈能够以更高的效率和规模帮助开发者识别问题所在，从而快速迭代。它通过反馈函数对输入、输出和中间结果进行质量评估，使实验评估更加高效.
                                    • 全面的反馈函数: TruLens 支持多种反馈函数，包括上下文相关性、真实性、回答相关性、全面性、有害或有毒语言、用户情感、语言不匹配、公平性和偏见等，开发者还可以提供自定义的反馈函数。这些反馈函数能够全面评估应用性能，帮助开发者在不同维度上提升应用质量并降低风险.
                                  • 应用场景与兼容性
                                    • 广泛的应用场景: TruLens 适用于多种基于 LLM 的应用，如检索增强生成（RAG）、摘要、辅助工具（如 Co-pilots）和代理等。它能够帮助开发者在这些场景中快速构建和优化应用，提高应用的可靠性和有效性.
                                    • 与 Python LLM 应用的兼容性: TruLens 可以与任何使用 Python 构建的基于 LLM 的应用兼容，这意味着开发者可以在各种基于 Python 的 LLM 应用项目中使用 TruLens，无需担心兼容性问题，从而扩大了其应用范围和使用场景.
                                  • 社区与支持
                                    • 社区参与与反馈: TruLens 鼓励用户积极参与社区，提供反馈以帮助其不断改进。用户可以通过 AI Quality Forum 的 Slack 社区加入 TruLens 社区，与其他开发者交流经验、分享最佳实践，并参与到 TruLens 的持续改进过程中.
                                    • 由 TruEra 和 Snowflake 支持: TruLens 最初由 TruEra 创建，是一个社区驱动的开源项目，已被数千名开发者使用。自 TruEra 被 Snowflake 收购后，Snowflake 积极监督和支持 TruLens 的开源开发，致力于推动 TruLens 的持续成长和创新.
                                   
                                  RAGChecker
                                  amazon-science • Updated Jan 17, 2025
                                   
                                  Ragas
                                   
                                   
                                   
                                   
                                   
                                   
                                   
                                   
                                  🎒
                                  离开乏味的皮囊，自由的灵魂在路上
                                  • Name: Alan Hsu
                                  • Tag: 随感、技术、经验、旅行、推荐、生活、音乐、电影 etc.
                                  • Email：xulanzhong521gmail.com
                                  • WeChat: Alan_Hsu_521
                                  notion image
                                  notion image
                                   
                                   
                                   

                                  打造个人跑步主页running_page

                                  2024-01-08 08:00:00

                                  📌
                                  看得清是知，做得到是行 → 知行合一
                                  ✍🏻
                                  爱跑步小伙伴的福音,个人主页构建,喜欢折腾的小伙伴看过来👀

                                  个人跑步主页 ⬇️

                                  Running Page
                                  Running Page
                                  https://run.xmylog.com/
                                  感谢大佬 @yihong0618
                                  以下是基本的搭建步骤,以keep数据为例,其他平台数据及配置详情参见
                                  github.com
                                  https://github.com/yihong0618/running_page/blob/master/README-CN.md

                                  搭建步骤

                                  1. Fork以下项目

                                  running_page
                                  yihong0618 • Updated May 13, 2025
                                  notion image

                                  2. 环境配置

                                  • 将自己github下的项目clone到本地
                                  • 安装及测试 (node >= 16 python >= 3.8)

                                  3. 个性化设置

                                   
                                  在仓库目录下找到 src/static/site-metadata.ts，找到以下内容并修改成你自己想要的。
                                   

                                  4. 下载数据到本地

                                  keep用户占比大,以keep举例,下载您的 Keep 数据到本地，别忘了在 total 页面生成可视化 SVG
                                  • Keep
                                  1. 获取 Keep 数据
                                      2. 示例
                                  1. 路线偏移修正
                                      2. 增加了 keep 可以导出 gpx 功能（因 keep 的原因，距离和速度会有一定缺失）, 执行如下命令，导出的 gpx 会加入到 GPX_OUT 中，方便上传到其它软件
                                   
                                  • Total Data Analysis
                                  1. 生成数据展示 默认是10公里 可自行修改
                                      2. special-distance 10 --special-distance2 20
                                      筛选10km 其中20km以上黄色显示
                                      notion image
                                      --min-distance 10.0 --special-distance 20 --special-distance2 40
                                      默认10km蓝色,20km黄色,40km红色
                                      notion image

                                  5. 提交代码至自己github

                                  6. server部署(两种部署方式,任选其一)

                                  使用 Vercel 部署

                                  1. vercel 连接你的 GitHub repo
                                  notion image
                                  1. import repo
                                  notion image
                                  1. 等待部署完毕
                                  1. 访问
                                   

                                  部署到 GitHub Pages

                                  1. 进入仓库的 "Settings -> GitHub Pages -> Source"，选择 "GitHub Actions"
                                  1. 进入仓库的 "Actions -> Workflows -> All Workflows"，选择左侧面板的 "Run Data Sync"，然后点击 "Run workflow"
                                  • "Run Data Sync" 将更新数据，然后触发 "Publish GitHub Pages" 工作流
                                  • 确认工作流运行没有错误
                                  1. 打开网站检查结果
                                  • 如果网站没有反映最新数据，请使用“F5”刷新页面
                                  • 某些浏览器 (比如 Chrome) 可能缓存网页不刷新，您需要使用 Ctrl+F5 (Windows) 或 Shift+Cmd+r (Mac) 强制清除缓存并重新加载页面
                                  1. 为 GitHub Actions 添加代码提交权限，访问仓库的 Settings > Actions > General页面，找到 Workflow permissions 的设置项，将选项配置为 Read and write permissions，支持 CI 将运动数据更新后提交到仓库中。
                                  1. 如果想把你的 running_page 部署在 xxx.github.io 而不是 xxx.github.io/run_page，需要做三点
                                  • 修改你的 fork 的 running_page 仓库改名为 xxx.github.io, xxx 是你 github 的 username
                                  • 修改 gh-pages.yml 中的 Build 模块，删除 ${{ github.event.repository.name }} 改为run: PATH_PREFIX=/ pnpm build 即可
                                  • src/static/site-metadata.ts 中 siteUrl: '' 即可

                                  7. 定时任务 GitHub Actions

                                  • 修改 GitHub Actions Token
                                      • 文件:.github/workflows/run_data_sync.yml
                                      将RUN_TYPE 改为 keep
                                      notion image
                                  • 在 repo Settings > Secrets 中增加你的 secret
                                      • KEEP_MOBILE 手机号
                                      KEEP_PASSWORD 密码
                                  notion image
                                  notion image
                                   
                                  • 然后手动执行 action
                                  notion image
                                   

                                  8. Github Cache

                                  • 把数据文件放在 GitHub Cache 中
                                      • run_data_sync.yml 中的 SAVE_DATA_IN_GITHUB_CACHE 设置为 true 时，可以把脚本抓取和中间产生的数据文件放到 GitHub Actions Cache 中。这样可以让你的 GitHub commit 历史和目录保持干净。
                                      如果你用 GitHub Pages 部署建议把这个值设置成 true。
                                       
                                      🎒
                                      离开乏味的皮囊，自由的灵魂在路上
                                      • Name: Alan Hsu
                                      • Tag: 随感、技术、经验、旅行、推荐、生活、音乐、电影 etc.
                                      • Email：xulanzhong521gmail.com
                                      • WeChat: Alan_Hsu_521
                                      notion image
                                      notion image