巴黎的清晨面包店的黄油香气会把整条街叫醒。买一只刚出炉的巧克力面包咬下去的酥皮破裂声几乎可以当作一天中最可靠的幸福指标。可是当这种幸福变得不稳定——今天这家起酥层次不够明天那家巧克力流心太甜——你就会开始想做一件看起来很无聊的事把全城的巧克力面包挨个排名。当时我在查找资料时正好撞见一个很有意思的分享有人在 Hacker News 上贴出一个项目标题就叫“Show HN: I ranked every Paris bakerys pain au chocolat using an LLM”。大意是他借助 LLM 对巴黎多家面包店的巧克力面包进行了排名。这个项目让我真正兴奋的点不在“AI 也能做美食测评”这种新闻式感叹而在于它把一件高度主观、高度依赖个人口味的任务硬生生拆成了一条可执行、可复核的流水线。这不是普通的“好吃排行榜”而是“用 LLM 处理真实世界评估问题”的绝佳案例。但它也藏着一层危险LLM 非常擅长用流畅的语言把偏好包装成客观结论。如果不理解它的评价机制不处理数据偏差和验证问题排名看起来越精细离真相可能越远。所以这篇文章不只是介绍这个项目而是拆开它背后的工程思路落到通用层面当你下一次想用 LLM 给任意对象打分排名时到底该怎么设计指标、怎么写提示词、怎么消除随机性、怎么让结果可以被复核。围绕这个目标我会按真实执行顺序展开先把问题定义到可测量的维度再设计评估用的评分卡和提示词然后解决多轮输出不稳定和偏差问题最后沉淀出一套可以复用到任意主观评估场景的通用框架。1. 先把问题定义清楚你要排名的不是“好吃”而是“可衡量的体验”所有用 LLM 做评估的项目第一步都不是写提示词而是定义“什么是好的结果”。如果你直接问模型“这家店的巧克力面包怎么样”它会给你一个看起来很有道理、但缺乏尺度的回答。这个回答可能适合写进游记却不适合用来排名排序。1.1 从“好吃”到“评分维度”大多数人对巧克力面包的预期是主观的。你觉得酥皮越脆越好他可能更喜欢软韧有嚼劲你觉得黄油香要浓他可能更在意巧克力苦甜比例。想用 LLM 做统一评估就得把“好吃”从整体感受拆成一组相对客观的二级维度。一个常见的拆法是参考面包师的工艺标准酥皮是否层次分明黄油香气是否明显但不过重巧克力夹心是否在烘烤后仍保持爆浆感甜度与可可苦味是否平衡出炉后的温度和结构是否合格外壳是否带有自然焦斑。显然LLM 无法直接吃到面包它只能基于文本描述来推断。但这个设计思路是对的没有评分维度你就没有让模型遵守的标尺维度越明确模型越能模仿一个“按标准打分的人”。在实际操作中还可以加入一条“整体评价”维度用于最终排序时的加权参考。但需要注意整体评价容易成为模型偷懒的出口。维度分解的意义不是为了追求极少见的客观而是为了让评估过程可以被检查当两个面包店出现争议分数时你能回看“酥皮得分”为什么低而不是面对一句“整体一般”的结论无处下手。建议开始设计评估流程时先花一小时把目标对象的评价维度写烂。维度不是越多越好而是每个维度都要能被看到、被描述、被验证。对巧克力面包来说5 个维度通常比 8 个维度更实用。1.2 谁来做数据采集自己探店 外部评论的限制有了评估维度之后下一个问题是数据从哪里来。理想情况是自己买回一批同品类面包现场拍照、记录温度、取固定部位的横截面甚至进行多次盲测。这种做法最可靠但人工成本太高不适合“城市级排名”。于是常见的替代方案是抓取互联网评论数据。你可以从点评平台、社交媒体、旅游攻略中收集大量用户对每家店的文字评价。理论上LLM 可以阅读这些文本抽取与酥皮、黄油、巧克力相关的描述再映射到评分卡上。但这里有两个致命限制平台评论的分布不均匀。有的店有几百条评论有的店只有两三句。评论数量本身就会影响最终得分的可信度。写评论的人往往带有情绪偏向。强烈喜欢或讨厌的人才更有动力留下文字中间派的声音很容易消失。如果原始项目采用的是外部公开评论那么最终排名更像是一种“舆情汇总”而不是“实测排名”。这并不是不行但需要在输出中明确指出排名依据是什么。如果只是用少量自己探店后的文字记录那么样本量太小排名可能会变成“作者个人口味 LLM 编造细节”。所以用 LLM 做评估前先想清楚你的数据是达人探店记录、平台公开评论还是全部自己采样的文本这个选择决定了排名的解释边界。1.3 为什么 LLM 适合做这件事既然数据这么难搞为什么还要用 LLM因为它擅长处理非结构化文本并把口语化的表达映射到结构化维度上。你可以把一条评论“可颂化得不错黄油味特别香就是巧克力有点少”直接转成“酥皮层次高、黄油香气高、巧克力含量低”这样的结构化数据。这种能力让 LLM 非常适合做“多档位的模糊评估”。不需要计算像素级的酥皮气泡也不需要分析油脂晶体结构只需要从语言里推断大概水准。本质上这是把“人写出来的感受”翻译成“一份可比较的评分表”。但我必须强调LLM 的优势是语言理解不是感官测量。它可以告诉你某家店更可能“香”却不能替你闻到香气。所以在整个评估流程里LLM 应该充当一个善于归纳、整理、给出候选结论的裁判助理而我们自己仍然是那个最终拍板的人。2. 用 LLM 评估前先建一张“评分卡”2.1 把评价标准写成评分卡而不是问“你觉得怎样”评分卡是评分任务里的核心工具。它定义了每个分数档位长什么样给模型和人类一套共同的尺子。设计评分卡时要避免太模糊。比如“酥皮层次”这一维度不要只写 1 到 5 分还要描述每个档位的典型表现分数酥皮层次描述1表面厚硬层次不明显切开后无蜂窝状分层2能看出分层但较薄缺乏空气感3有清晰多层结构咬下时有轻微破裂感4层次分明内部有较多空隙口感起酥明显5极薄的酥皮层均匀展开质地轻盈咬下时发出明显脆响同样黄油香气、巧克力饱满度、甜苦平衡、余味等都可以构建类似的评分卡。当你把所有维度写清楚后提示词的内容也就有了骨架。这里的关键是不要试图一次性找模型帮你定义标准而是你先准备一版基础标准再让模型根据你的标准来打分。提示评分卡的语句越具体LLM 越不容易被“平均分”带跑。如果你只写“好吃程度”模型会把所有店都拉向中间值。2.2 提示词模板让 LLM 输出结构化结果和证据片段评分卡确定后下一步是构造提示词。一个有效的评估提示词不只让模型给分还要要求模型输出支持这个分数的关键线索。这种设计既能降低幻觉率也方便后续人工检查。下面是一个可以直接套用的提示词结构示例以巧克力面包为例你是一名烘焙产品评测分析师。请根据以下评分标准对一家面包店的巧克力面包进行结构化评估。 评分维度 - 酥皮层次1-5 - 黄油香气1-5 - 巧克力饱满度1-5 - 甜苦平衡1-5 - 整体体验1-5 评分规则 1. 先阅读用户提供的评论或观察记录。 2. 如果信息不足某个维度允许标为 unknown不要猜。 3. 每个分数必须从评论原文中引用一句支持证据。 4. 只能输出 JSON 对象不要输出其他内容。 用户提供的文本 {这里放入评论文本或观察记录}这段提示词看起来简单但有几个设计细节非常关键“信息不足允许标注 unknown”这是最容易被忽视的一条。很多 LLM 在缺少证据时会强行补全一个猜测值。允许 unknown 能大幅减少幻觉。“引用一句支持证据”让模型必须在使用者提供的文本里寻找依据而不是凭空编造。“只能输出 JSON”方便后续程序解析也防止模型写一大堆解释盖过结论。在实际项目中你可能会遇到输出格式混乱的情况。这时不要急着换模型先用一个固定函数解析 JSON并在提示词末尾增加一行“不要输出 markdown 代码块标记”。这种小调整往往就能解决大多数格式问题。2.3 为什么不要相信单轮回答采样的必要性完成基础提示词后用一条样例跑一轮结果看起来可能不错。但如果连续跑两三次你就会发现同一个文本可能得到不同的分数。这源于 LLM 的采样随机性尤其是当你没有把 temperature 参数调到很低时。有些人会直接说那我温度调到 0 不就行了理论上当 temperature 0 时模型对同一输入的输出会更稳定但这并不代表它一定正确。更麻烦的是如果你用多个不同采集来源的文本拼在一起输入顺序变化也会导致不同的结果。顺序、标点、空格、甚至换行都可能让模型关注到不同信息。所以稳妥做法不是依靠单次输出而是对同一输入运行多次独立采样然后做统计聚合。这样既降低了随机性也能观察模型在不同“视角”下的波动情况。后面我会专门讲怎么聚合。3. 用 LLM 做排名最容易踩的三个坑3.1 坑一输入文本质量决定评估上限再强的 LLM 也救不了脏乱差的数据。如果输入文本里全是营销话术、重复的标签、无意义的感叹词模型提取的评估证据一定偏。常见的问题有以下几类编码问题法语字符、特殊符号在某些平台会乱码导致关键词无法识别。无语义片段比如评论里全是“好”“棒”“不错”这种短评模型很难区分差别。重复刷评同一家店的多条评论内容相似会让模型反复强化同一个印象。这些问题的解法通常在 LLM 调用之前。先做简单的数据清洗去重、去 emoji、过滤过短评论、统一繁体简体或保留原文并尽量保留完整的句子结构。经验我用这类评估项目踩过最深的一个坑是抓取文本时把大量 HTML 标签带进去了。模型竟然把“/店名/”误当成面包店的真实特征给了一家店额外加分。后来强烈建议任何文本进 LLM 前都先做一轮肉眼抽查。3.2 坑二历史评分和评论长度会污染偏好LLM 对文本里的数字和长度很敏感。如果一条评论是这样“这家店评分 4.8环境不错服务很好第一次来的旅客推荐。”模型很有可能被 4.8 这个数字带跑给出偏高的评估。即使你只要求它看描述它也会把数字当作强信号。另外评论长度也会形成“补偿效应”。模型遇到长篇详细评论时倾向于认为内容更可信、更专业从而在多个维度上给出更高分。但实际上很多长评只是写作者表达欲强并不代表产品本身更好。要规避这个问题可以在提示词里强制加入一句“请忽略评论中的评分、星级、价格和博主昵称只基于对产品或体验的事实描述进行推断。”同时在聚合阶段可以按评论长度和来源数进行加权归一化避免长度影响最终结果。3.3 坑三你以为在“排名”其实在做“聚类摘要”如果你的样本量很小比如每家店只有一条评论那么直接把所有店打分排序得到的不是“城市咖啡水平排名”而是“评论者个人语气激烈程度排名”。在这种情况下更好的做法是先让 LLM 帮你把评论做主题聚类看看主要争议集中在哪些维度上再做人工判断。比如假设某家店的评论文本反复出现“外皮太硬”“像面包而不是可颂”这其实已经告诉你它的主要短板并不需要模型给出一个精确的 3.7 分。聚类摘要在小样本下比排名更可靠。只有当每家店的评论文本数量足够多且量表一致时排名才有统计意义。所以一个更合理的执行顺序是先做文本清洗与去重。用 LLM 抽取每家店的关键特征形成特征列表。对所有特征做主题聚类找出大众普遍关注的维度。当样本足够时才进入评分排名阶段。这个顺序能避免“用几百条文本强行生成一个排名”的伪精确感。4. 如何让 LLM 评估结果稳定、可复现、可解释4.1 多轮采样 中位数聚合假设你已经对同一输入跑了 5 次评估接下来怎么把这些结果合成一个最终分数直接取平均值并不总是最好的因为一次异常高的离群值会把分数拉高。更稳妥的方法是取中位数并同时记录标准差。维度打分1打分2打分3打分4打分5中位数标准差酥皮层次4344340.55黄油香气3433430.55巧克力饱满度2232220.45如果某个维度的标准差超过 1意味着模型对这段文本的判断很不稳定。这时不要急着取中位数而是回到原始输入检查是不是文本本身信息太模糊是不是多个不同店铺的评论被混在一起了或者维度定义还不够清晰编码过程中可以把每个维度绑定一个“证据片段列表”。当最终分数出现争议时你只需打开证据列表就能判断哪条可信。这比直接给一个裸分数友善得多。经验5 到 7 次采样通常是一个不错的起点。次数太少波动没有被平滑次数太多调用成本和时间都会明显上升。实际项目中我会先把 temperature 调低到 0.2 左右再跑 5 次。如果标准差普遍很低再考虑增加到 7 次。4.2 校准用已知高/中/低分样本校正一家店的评论是“酥皮太干”另一家的评论是“黄油香味布满口腔”。LLM 给这两者的分差可能很明显但这种绝对分数不一定能反映你个人的真实偏好。这时可以用“锚定样本”做校准。具体操作是选 3 个你亲自吃过且心里已经确定档位的文本样本分别代表“明显优秀”“中等水准”“明显普通”让 LLM 给这些样本打分。然后观察 LLM 输出的分差和你的主观判断是否一致。如果 LLM 把“中等水准”的那家给到了 4 分而你认为它只有 2.5 分就说明提示词里的评分卡太宽松了。你可以调整评分卡中的描述比如把“3 分”的定义写得更高一些。或者在校准时做一个线性修正最终分 (LLM 分 - 中等样本分) / (优秀样本分 - 中等样本分) × 期望区间。校准看起来麻烦却是让评估结果具备解释力的关键一步。否则你的“满分 5 分”和另一个人的“满分 5 分”根本不是同一把尺子。4.3 排查链路当 LLM 输出异常时按什么顺序检查用 LLM 做评估很少能一次跑通。最常见的问题是输出 JSON 格式错误、某个维度总是 unknown、分数明显偏离直觉、多家店全是 4 分。遇到这些情况按顺序排查先看输入内容文本是不是在传入前被截断了是否包含乱码或多余的 HTML是否一次塞了很多店铺评论导致模型注意力分散再看提示词维度描述是否具体有没有明确要求“忽略星级”有没有允许 unknown再看采样参数temperature 是否过高是否使用了 num_beams 或 top_p 等影响随机性的参数再看聚合方式只用一轮结果就下结论样本量是否太少标准差是不是太大最后看模型边界当前模型是否对长文本和外部知识有限制有些模型会拒绝评估某些主观领域或者自身对欧洲食物名词不敏感。这套链路并不特殊但它能帮你在几分钟内定位大多数问题而不是盲目重写整段代码。实际项目中出现“全是 4 分”时大概率是提示词里没有要求模型使用完整分数区间。你可以增加一句“请优先使用 1、2、3、4、5 中的全部等级不要集中在中间分数。”这一句话往往就能改变很多。5. 从“巧克力面包排名”到“可复用的评估框架”5.1 方法论沉淀定义指标 → 设计提示词 → 稳定化 → 验证这个项目真正值得学习的不是“巴黎面包店榜单”本身而是它背后的方法论。我把整套过程压缩成一个四步框架第一步定义指标。把目标对象的评价维度拆成 3 到 6 个可观察、可描述的子项每个子项要有明确的档位描述。不要直接问“好不好”要问“哪一个维度表现如何”。第二步设计提示词。提示词里必须包含评分卡、评分规则、unknown 选项和结构化输出要求。同时明确告诉模型忽略哪些干扰信息比如星级、价格、作者昵称。第三步稳定化输出。对同一输入跑多次独立采样取中位数记录标准差。如果标准差过大回到提示词和输入数据去修正而不是在聚合阶段硬缝合。第四步人工验证。至少抽取 10% 的样本做人工复核。如果你发现某家店的模型分数和你的真实体验有系统性偏差就回去校准评分卡。验证不是可选项而是流程的一部分。这套框架并不只适用于巧克力面包。把目标对象换成咖啡店、编程框架、技术会议甚至招聘简历逻辑都成立。核心思想是一致的LLM 不是“主观评价生成器”而是“主观评估的辅助执行器”。5.2 适用与不适用场景任何方法论都有边界。这套“LLM 评估框架”适合的是当你需要从大量文本中提取信号、对候选对象做初步分层、快速给出一个可解释的相对排序并且有人工复核条件时。它不太适合哪些场景如果评估对象需要有严格量化标准比如食物本身的营养成分、工业产品的性能指标、医疗诊断等LLM 的文字推断就不能作为最终依据。也就是说它可以帮你从评论里发现“很多顾客提到这家店的巧克力放得太少”但不能替你测量每只面包里巧克力的克重。另一个边界是数据代表性。如果你要排名的是“巴黎全部面包店”但你只收集了一家点评平台上前几名门店的评论那么你做出来的并不是全城排名最多只能算“热门网络评论榜”。要减少误解最好在输出列表里标注“依据 123 条公开评论文本生成并非专业盲测”。界限这套框架的价值不是替代真实的感官体验而是压缩大量文字信息让有判断力的人更快看到模式。如果你拿它替代最终决定一定会被随机性和数据偏差狠狠教训。5.3 真实体验这个项目改变的其实不是“早餐”而是我们怎么和 LLM 协作回到最初那个“用 LLM 给巴黎巧克力面包排名”的项目。它真正有价值的不是最终榜单而是它迫使作者和所有读者把“好吃”这件本来很私人的事情变成了一个可以讨论、可以追责、可以改进的工程问题。你可能会觉得用 LLM 来排面包店有点杀鸡用牛刀。但当你把这种思路放到更实际的场景里——比如用 LLM 筛选用户反馈、评估候选人简历、对比产品方案、整理客户访谈——你会发现自己突然拥有了一套不依赖个人情绪漂移的协作方式。LLM 能帮你快速建立初稿但你依然掌握定义标准和最终验证的权力。这个项目真正的遗产是它提醒我们不要迷信 LLM 给出结论而要借它的语言理解能力去处理那些过去需要人工阅读大量文本的“低效任务”。至于那些排名结果把它当作一种基于语言线索的建议而不是判决书可能才是更健康的使用姿势。所以下一次你再遇到一个“AI 帮我把所有城市排名”的项目时不要再感叹 AI 真厉害。你可以多看三件事它怎么定义指标它怎么应对随机性它有没有让输出结果可以被人工复核。做到这三点你就能判断这是一个玩具还是一件真正能改变工作方式的工具。