从汽车口碑到市场信号：跨来源清洗、相似检测与查询系统复盘

消费者口碑看起来是文本数据，真正落到市场研究系统里，却首先是一个领域建模问题：不同网站的品牌、厂商、车系、年款和具体车型层级不同；同一评分维度可能有不同字段名；购买价格、行驶里程和发布时间可能缺失或异常；同一段评论还可能跨来源重复出现。

这个项目为汽车市场研究建设了一套内部数据工具。它没有把重点放在自动生成结论，而是先把车型、配置、评分和口碑整理成可筛选、可比较、可导出的样本。源码表明，后端不只是一个展示接口，而包含一套独立的数据清洗命令、统一领域模型、来源映射、标签聚合、评分计算和相似评论检测。

证据怎样相互印证

需求文档定义了汽车分类、车型配置、口碑字段、筛选、导出和异常评论处理；工单集中记录排序、停售车型、日期、里程、新能源字段、来源切换和标签过滤等缺陷；Go 后端与 Vue 前端则给出了实际数据结构和调用逻辑。

三者并不总是一致。例如需求曾写导出为 CSV，最终代码实际生成 XLSX；“车型对比”和“关键词搜索”仍是待办，而配置和评论导出已经存在；相似度筛查工单停在处理中，但源码已经有可执行实现。本文以源码确认“实现过”，以工单状态说明“是否验收仍不确定”。

统一模型从四类集合开始

清洗后的数据保存在四类主要集合中：

索引模型用层级值区分厂商或品牌、车系和车型，并同时保留两个来源的外部标识。它还保存名称前缀、拼音、价格区间、图片、车型标签和评论标签。评论模型则把正文设计为“维度名称到文本”的映射，而不是一个不可分割的大字符串，这使空间、动力、操控、油耗、舒适性、外观、内饰和性价比可以分别筛选和导出。

这里有一个值得保留的设计：来源字段没有直接成为主键。内部索引负责连接业务层级，外部标识只用于回查来源数据。否则同一车型在两个来源中会天然变成两个对象，跨来源评分和评论很难聚合。

清洗程序是一组可组合任务

数据清洗入口接收任务名称和来源，按顺序执行不同处理：

1. index 从来源库生成车型层级，补充拼音首字母，并为父标识、名称建立索引。
2. series 整合车系信息。
3. car 读取车型配置、价格、图片和热度，写入统一车型集合。
4. comment 按来源转换口碑，支持按最近若干天增量读取。
5. label 把来源标签、标签分组和主观倾向回写到评论、车型和索引。
6. score 重新计算车型评分。
7. unique 对全量评论执行精确和近似重复检测。

程序可以按逗号组合多个任务，也可配置成每天凌晨执行。增量模式会把当前日期向前推指定天数，作为来源记录更新时间的下界；写入使用按内部标识更新或插入，避免每次简单追加。它已经具备批处理骨架，但没有看到任务依赖图、批次状态表或失败后的精确续跑点，因此任务顺序仍依赖操作者正确配置。

两个来源如何被压成同一条评论

第一个来源的数据本身按多个“场景”对象组织。清洗器逐一读取空间、动力、操控、能耗、舒适性、外观、内饰和性价比场景，把场景里的分数写入固定字段，把“感受名称—感受文本”放进正文映射；另外还读取最满意、最不满意、选择原因和电池体验等可选场景。

第二个来源则使用扁平字段。转换器手工映射同样的八个评分和正文维度，并补充服务与其他描述。两种来源最终都输出：

• 来源前缀加原评论标识组成的内部评论标识；
• 统一车型标识与父级车系标识；
• 车型名、用户、经销商、地点、购车时间、价格、能耗和里程；
• 八个评分、购车目的、发表时间、标题和分段正文；
• 质量、浏览数、支持数、标签和异常标记。

转换代码还修正了负数里程，把它归零；购买价格按来源单位换算；不同来源的时间格式分别解析。新能源车把油耗改称耗电量主要出现在产品和前端显示要求中，底层字段仍沿用统一的能耗字段，这是一种兼容旧接口的做法，但会让字段语义依赖车型能源类型。

标签并不是关键词搜索

标签清洗读取来源中的“组合标签”，再查标签所属分组和情感键。标签被同时写入三处：具体评论获得标签与标签组，车型获得聚合标签，索引保存可供筛选的标签对象及其评论数。

标签对象包含名称、所属分组、主观倾向和计数。主观倾向枚举实际只有“无、缺点、优点”，没有独立的异常评论类型。历史工单也要求把“水军”从普通口碑标签中移出，改为表格字段单独筛选。这是合理的语义分离：评论说“空间局促”属于内容观点，评论疑似复制属于数据质量，两者不应混在同一标签体系里。

评分怎样计算

单车型评分的算法很直接：读取该车型全部评论，把八个维度分别转换为浮点数、求和，再除以评论总数；总分是八个维度平均分的算术平均。车系或年款层面的汇总则更严谨一些：先读取多个车型已经计算好的均分和参与数，用参与数作权重重新计算八个维度，再求总分，同时从各车型指导价中计算最小值与最大值。

也就是说，车型汇总公式可以写成：

维度均分 = Σ(车型维度均分 × 车型评论数) ÷ Σ车型评论数

这避免了“只有两条评论的车型”和“有数百条评论的车型”被赋予相同权重。价格若只有一个有效值就显示单值，否则显示区间。

不过，单车型算法把解析失败或缺失评分当作零，同时仍用全部评论数作分母，会系统性压低缺失较多的车型；总分又固定除以八，没有按实际有效维度数调整。这是需要重建时修复的统计偏差。

精确重复和 SimHash 近重复

相似评论检测是项目最有技术含量的部分之一。处理流程如下：

1. 把一条评论正文映射中的“维度名+正文”组成数组。
2. 对数组排序，消除映射遍历顺序的影响。
3. 拼接文本，删除空白和常见中英文标点。
4. 计算 MD5；相同摘要的全部评论标为异常。
5. 对此前未命中精确重复的评论计算 64 位 SimHash。
6. 与内存中所有既有指纹比较，汉明距离小于 10 时，把当前评论和首个命中对象都标为异常。

这个实现能发现换序、删改少量词语后的近重复，也保留原文供研究人员复核。文档中的规则还提出跨库重复、异常账号、认证车型与购买车型不一致、时间里程异常等信号，但源码只明确实现了来源已有标记、精确重复和 SimHash 近重复，不能把整套规则清单都视为落地。

这里还有两个重要边界。第一，异常字段只是风险标记，不足以断言作者身份或内容真假。第二，近似检测把每个新指纹与全部历史指纹逐一比较，时间复杂度接近 O(n²)，数据量增大后会成为瓶颈；它还在首次命中后停止，没有保存相似组、距离或规则版本，难以解释为什么被标记。

下面的等价伪代码依据去重实现整理，突出精确摘要与 SimHash 两级判断；它不是原源码，也没有展示数据库更新细节：

def mark_near_duplicates(comments):
    exact = {}
    fingerprints = []
    for comment in comments:
        text = normalize(sort_sections(comment.content))
        digest = md5(text)
        if digest in exact:
            flag_pair(comment.id, exact[digest], "exact")
            continue
        value = simhash64(text)
        for prior_id, prior_value in fingerprints:
            distance = hamming(value, prior_value)
            if distance < 10:
                flag_pair(comment.id, prior_id, distance)
                break
        exact[digest] = comment.id
        fingerprints.append((comment.id, value))

查询接口如何组织筛选与导出

后端通过代码注解生成 REST 路由和接口文档。车辆服务提供：索引级联、车型列表与数量、评论列表与数量、标签、评分、热门入口、单车详情，以及车型和评论表格导出。

评论查询把时间区间、车型标签、标签组、单标签、质量、来源、排序、偏移量和条数拼成 MongoDB 条件；车型查询使用相近的标签与来源条件。导出并非另外再查一套口径，而是通过中间层复用已筛出的车型或评论，然后生成 XLSX。

车型导出按基本参数、车身、发动机、电动机、变速箱、底盘、安全、座椅、灯光等配置组展开；评论导出先写固定列，再根据正文映射中实际出现的维度动态扩展列。这种设计能容纳来源新增的正文小节，但同一批数据的列顺序受首次遇到字段的顺序影响，最好改成显式字段字典。

跨来源切换还有一个模糊匹配函数：先按目标层级和父级筛选候选，再计算名称字符的顺序命中率；若双方都有名称前缀，则以名称得分占六成、前缀平均得分占四成。它能在某来源缺少映射标识时找到近似车系或车型，但只是字符子序列启发式，不是可审计的实体匹配。

产品取舍来自真实使用场景

会议记录显示，团队讨论过在平台内做更多图表与车型比较，最后优先保证数据清洗、二十余项筛选和导出，避免重复开发通用电子表格已经擅长的分析能力。这是一个清晰的内部工具决策：平台负责把原料变成可信样本，研究人员继续在熟悉的分析环境中处理。

工单也说明产品经历了集中整改。已完成事项覆盖排序、在售与停售顺序、标签显示、异常日期、价格区间、级联选择残留、第二来源展示、新能源字段、负数里程和配置导出；车型对比、第三来源和关键词搜索仍未确认完成。实际代码的二百余次后端提交集中在四个月内，频繁出现“清洗、修复、重新生成、优化查询”，反映出交付重点确实在数据口径和联调，而非单纯页面制作。

源码中值得保留与修复的部分

值得保留的设计包括统一内部索引、来源适配器、分段正文、风险标签不直接删除数据、聚合评分按样本量加权，以及查询与导出复用同一筛选口径。

需要优先修复的问题包括：

• 层级判断依赖内部标识中下划线的数量，标识格式一变，查询语义就会改变。
• 热门列表按计数升序取十条，实际可能返回最少使用的对象，和“热门”命名相反。
• 时间解析后调用时区转换却没有接收返回值，时区并未真正写回。
• 评分解析失败按零处理，缺失维度污染平均值。
• 标签去重逻辑会把在前一个索引中不属于目标分组的标签加入跳过集合，即使后续索引中该标签属于目标分组，也可能永远不再加入。
• SimHash 全量两两比较既慢又没有分桶、距离证据和相似组；重复任务也不会先重置旧标记。
• 来源模糊匹配没有阈值和“无可靠候选”状态，低分候选也可能被选中。
• 配置中曾保存固定连接信息；这些历史值应当视为不可继续使用，并从运行时配置和版本历史中隔离。
• 测试代码不足以覆盖来源映射、缺失字段、评分和相似检测这些高风险规则。

如果今天重建

新的实现可以保留“清洗优先”的产品边界，同时把数据管线做成可追踪系统：

1. 用稳定 UUID 表示品牌、厂商、车系、年款和车型，来源标识进入独立映射表，不再编码进主键格式。
2. 每条原始记录保留来源快照，标准化结果记录转换器版本、批次和字段级错误。
3. 评分只对有效观测求平均，同时返回每个维度的有效样本数和缺失率。
4. 精确摘要用于快速去重；SimHash 先按若干位前缀分桶，再比较候选，并保存距离、匹配对象与规则版本。
5. 把异常账号、车型不一致、时间里程异常拆成独立证据，不合并成一个不可解释的真假字段。
6. 实体跨来源映射采用名称、父级、年份、配置等多特征评分，低于阈值进入人工确认队列。
7. 为每个来源建立黄金样本，回归验证字段完整率、评分误差、重复检测准确率和导出列稳定性。

这个项目的价值不在于“收集了很多评论”，而在于它已经摸到汽车口碑分析的真实难点：同一研究问题必须跨过车型实体、来源差异、文本质量和统计口径四道门槛。只有把这些门槛的处理过程变成可追踪证据，评论才能从网页内容变成市场信号。

证据边界

现有材料包括二十余条汽车项目工单、需求与会议文档、Go 后端、Vue 前端和一个早期采集仓库。后端保留二百余次提交，前端保留三十余次提交。源码可以确认双来源转换、车型与评论模型、标签聚合、八维评分、精确及近似重复检测、组合筛选和 XLSX 导出。

本文没有重新连接历史数据库，也没有可复核的准确率、覆盖率、实际用户数或营销结果。文档提出但源码未证实的账号异常、购买车型校验等规则仍属于设计；车型对比、关键词搜索和第三来源属于未完成或待确认能力。异常评论标记只代表规则命中，不代表对内容真实性的事实判断。