public class ExampleDiversityAnalyzer {
    
    private final EmbeddingClient embeddingClient;
    
    /**
     * 分析示例集的多样性
     * 返回0-1的分数，1表示完全多样，0表示完全重复
     */
    public double analyzeDiversity(List<FewShotExample> examples) {
        if (examples.size() < 2) return 1.0;
        
        // 获取所有示例输入的向量表示
        List<float[]> embeddings = examples.stream()
            .map(e -> embeddingClient.embed(e.getInput()))
            .collect(Collectors.toList());
        
        // 计算平均成对距离（作为多样性指标）
        double totalDistance = 0;
        int pairCount = 0;
        
        for (int i = 0; i < embeddings.size(); i++) {
            for (int j = i + 1; j < embeddings.size(); j++) {
                totalDistance += cosineDissimilarity(embeddings.get(i), embeddings.get(j));
                pairCount++;
            }
        }
        
        return totalDistance / pairCount;
    }
    
    /**
     * 从候选示例池中选出最多样化的k个示例
     * 使用最大最小距离（Max-Min Distance）贪心算法
     */
    public List<FewShotExample> selectMostDiverse(List<FewShotExample> candidates, int k) {
        if (candidates.size() <= k) return candidates;
        
        List<float[]> embeddings = candidates.stream()
            .map(e -> embeddingClient.embed(e.getInput()))
            .collect(Collectors.toList());
        
        List<Integer> selectedIndices = new ArrayList<>();
        
        // 随机选第一个
        selectedIndices.add(0);
        
        // 贪心地选后续的，每次选与已选集合距离最大的
        while (selectedIndices.size() < k) {
            double maxMinDist = -1;
            int bestCandidate = -1;
            
            for (int i = 0; i < candidates.size(); i++) {
                if (selectedIndices.contains(i)) continue;
                
                // 计算候选i与已选集合的最小距离
                double minDist = selectedIndices.stream()
                    .mapToDouble(j -> cosineDissimilarity(embeddings.get(i), embeddings.get(j)))
                    .min()
                    .orElse(0);
                
                if (minDist > maxMinDist) {
                    maxMinDist = minDist;
                    bestCandidate = i;
                }
            }
            
            selectedIndices.add(bestCandidate);
        }
        
        return selectedIndices.stream()
            .map(candidates::get)
            .collect(Collectors.toList());
    }
    
    private double cosineDissimilarity(float[] a, float[] b) {
        double dotProduct = 0, normA = 0, normB = 0;
        for (int i = 0; i < a.length; i++) {
            dotProduct += a[i] * b[i];
            normA += a[i] * a[i];
            normB += b[i] * b[i];
        }
        double similarity = dotProduct / (Math.sqrt(normA) * Math.sqrt(normB));
        return 1 - similarity; // 转为距离
    }
}

维度四：难度梯度

这一维度很多文章没提到，但我认为很重要。示例从简单到复杂排列，能让模型建立更好的"难度感知"。

好的排列顺序：

一个标准、简单的案例（建立基础理解）
一到两个略有变化的案例（扩展边界）
一个边界情况或稍难的案例（确立处理策略）

坏的排列顺序：全是最复杂的案例，或者随机排列没有逻辑。

维度五：格式一致性

所有示例的格式要统一。如果有些示例输出是JSON，有些是Markdown表格，有些是纯文本，模型会对"到底用什么格式"感到困惑。

这个问题在团队协作时特别容易出现——不同人负责标注不同批次的示例，格式就慢慢漂移了。

示例选择的工程化流程

把上面的维度落到代码里，我建议一个五步流程：

@Service
public class FewShotExampleSelector {
    
    @Autowired
    private ExampleDiversityAnalyzer diversityAnalyzer;
    
    @Autowired
    private ExampleAccuracyValidator accuracyValidator;
    
    @Autowired
    private ExampleDifficultyEstimator difficultyEstimator;
    
    /**
     * 从候选池中为特定查询选择最合适的Few-Shot示例
     */
    public List<FewShotExample> selectForQuery(
            List<FewShotExample> candidatePool,
            String queryInput,
            int targetCount) {
        
        // 第一步：准确性过滤
        List<FewShotExample> validExamples = candidatePool.stream()
            .filter(e -> accuracyValidator.validate(e).isValid())
            .collect(Collectors.toList());
        
        log.info("准确性过滤：{} -> {}", candidatePool.size(), validExamples.size());
        
        // 第二步：与查询的相关性排序
        // 优先选与当前查询语义相似的示例
        List<FewShotExample> relevantExamples = selectByRelevance(validExamples, queryInput, targetCount * 3);
        
        // 第三步：多样性优化（从相关性候选中选最多样的）
        List<FewShotExample> diverseExamples = diversityAnalyzer.selectMostDiverse(
            relevantExamples, targetCount);
        
        // 第四步：按难度排序
        diverseExamples.sort(Comparator.comparingDouble(
            e -> difficultyEstimator.estimate(e)));
        
        // 第五步：格式规范化
        return diverseExamples.stream()
            .map(this::normalizeFormat)
            .collect(Collectors.toList());
    }
    
    /**
     * 基于语义相似度选择相关示例
     */
    private List<FewShotExample> selectByRelevance(
            List<FewShotExample> examples,
            String queryInput,
            int topK) {
        
        float[] queryEmbedding = embeddingClient.embed(queryInput);
        
        return examples.stream()
            .sorted((a, b) -> {
                float[] embA = embeddingClient.embed(a.getInput());
                float[] embB = embeddingClient.embed(b.getInput());
                double simA = cosineSimilarity(queryEmbedding, embA);
                double simB = cosineSimilarity(queryEmbedding, embB);
                return Double.compare(simB, simA); // 降序
            })
            .limit(topK)
            .collect(Collectors.toList());
    }
}

示例排列顺序的影响

研究发现，即使是同一批示例，排列顺序不同，效果也会不同。这个现象叫"示例顺序偏差"（Example Order Bias）。

我做了一个实验，用同样的5个示例，测试了不同排列顺序下的准确率。

实验结果（20个测试案例的准确率）：

随机顺序：约74%
简单→复杂：约82%
最相关示例放最后：约85%
简单→复杂 + 最相关放最后：约88%

最相关的示例放在最后（紧邻测试问题），这个发现有点反直觉，但实际上符合"近因效应"——模型对最近读到的内容权重更高。

public class ExampleOrderOptimizer {
    
    /**
     * 对已选定的示例进行排列顺序优化
     * 策略：简单到复杂，最相关的放最后
     */
    public List<FewShotExample> optimize(
            List<FewShotExample> examples,
            String queryInput) {
        
        if (examples.size() <= 1) return examples;
        
        // 找出与查询最相关的示例
        FewShotExample mostRelevant = findMostRelevant(examples, queryInput);
        List<FewShotExample> remaining = examples.stream()
            .filter(e -> !e.equals(mostRelevant))
            .collect(Collectors.toList());
        
        // 剩余示例按难度排序（简单→复杂）
        remaining.sort(Comparator.comparingDouble(e -> difficultyEstimator.estimate(e)));
        
        // 最相关的放最后
        remaining.add(mostRelevant);
        
        return remaining;
    }
}

动态示例选择 vs 静态示例集

两种策略各有适用场景，不能一概而论：

静态示例集：

所有用户的请求使用相同的示例
优点：实现简单，延迟低，方便测试和版本管理
缺点：示例无法针对具体查询优化
适合：任务类型单一、查询分布集中的场景

动态示例选择：

根据每个查询，从示例库中实时检索最相关的示例
优点：示例与查询高度相关，效果通常更好
缺点：需要维护示例库，增加延迟，增加成本
适合：任务类型多样、查询分布分散的场景

@Service
public class AdaptiveFewShotStrategy {
    
    @Autowired
    private FewShotExampleSelector dynamicSelector;
    
    @Autowired
    private List<FewShotExample> staticExampleSet;
    
    @Autowired
    private QueryClassifier queryClassifier;
    
    /**
     * 根据查询特征自动选择策略
     */
    public List<FewShotExample> select(String queryInput, TaskConfig taskConfig) {
        QueryType queryType = queryClassifier.classify(queryInput);
        
        // 简单标准查询用静态示例（省成本省延迟）
        if (queryType == QueryType.STANDARD && taskConfig.isLatencySensitive()) {
            return staticExampleSet;
        }
        
        // 复杂查询或边界情况用动态选择
        return dynamicSelector.selectForQuery(
            taskConfig.getExamplePool(),
            queryInput,
            taskConfig.getTargetExampleCount()
        );
    }
}

一个经常被问的问题：负面示例

要不要在Few-Shot里加入"反例"——告诉模型什么输出是错误的？

我的经验是：谨慎用，有条件地用。

适合加负面示例的场景：

有一类常见的、容易犯的错误，正面示例无法有效避免
任务对准确率要求极高，宁可多花Token

不适合加负面示例的场景：

Token预算紧张（负面示例消耗额外Token，但价值不一定对等）
错误示例可能让模型"学到"错误的模式（确实存在这个风险）

如果要用负面示例，格式要非常清晰：

【错误示例】
输入：……
错误输出：……（错误原因：这里输出了甲方代表而不是甲方公司名称）
正确输出：……

要明确标注"这是错误的"以及"为什么错"，不能只列出错误输出让模型自己猜。

示例质量评估的自动化

手工评估Few-Shot示例的质量费时费力，可以做一定程度的自动化：

@Service
public class AutoFewShotQualityAssessor {
    
    private final LLMClient llmClient;
    
    /**
     * 留一法（Leave-One-Out）评估示例的贡献度
     * 移除某个示例后，如果整体效果下降，说明这个示例有价值
     */
    public Map<FewShotExample, Double> evaluateContributions(
            List<FewShotExample> allExamples,
            List<EvaluationCase> evalCases) {
        
        // 先评估完整示例集的基准分数
        double baselineScore = evaluateExampleSet(allExamples, evalCases);
        
        Map<FewShotExample, Double> contributions = new HashMap<>();
        
        for (FewShotExample exampleToRemove : allExamples) {
            // 创建去掉当前示例的子集
            List<FewShotExample> reducedSet = allExamples.stream()
                .filter(e -> !e.equals(exampleToRemove))
                .collect(Collectors.toList());
            
            // 评估去掉后的分数
            double reducedScore = evaluateExampleSet(reducedSet, evalCases);
            
            // 贡献度 = 去掉它之后的分数下降量
            double contribution = baselineScore - reducedScore;
            contributions.put(exampleToRemove, contribution);
            
            log.debug("示例 [{}] 贡献度: {}", exampleToRemove.getId(), contribution);
        }
        
        return contributions;
    }
    
    private double evaluateExampleSet(
            List<FewShotExample> examples,
            List<EvaluationCase> evalCases) {
        
        String prompt = buildPromptWithExamples(examples);
        int correctCount = 0;
        
        for (EvaluationCase evalCase : evalCases) {
            String actualOutput = llmClient.complete(prompt, evalCase.getInput());
            if (isCorrect(actualOutput, evalCase.getExpectedOutput())) {
                correctCount++;
            }
        }
        
        return (double) correctCount / evalCases.size();
    }
}

用这个留一法定期审查示例集，可以找出那些"负贡献"的示例（去掉它反而更好），果断删掉。

实际效果的总结

用以上方法系统化地优化Few-Shot示例之后，在我经历的几个项目里，平均效果提升情况大概是：

信息抽取类任务：准确率提升8-15%
分类类任务：准确率提升5-10%
生成类任务：人工评分提升明显，但比较难量化

当然，基础大不同，提升幅度也会不同。但这个方向的优化确实是被很多人忽视的——大家把精力都放在系统提示的措辞上，却忽视了示例本身的质量。

小结

Few-Shot示例的质量不是主观感受，是可以量化评估、系统化优化的。代表性、准确性、多样性、难度梯度、格式一致性，这五个维度构成了一个完整的评估框架。

结合语义检索做动态示例选择，结合留一法做示例贡献度评估，基本上能把Few-Shot的效果做到接近上限。