草庐IT

大数据 + VR 全景技术重塑“二手车买车场景”

轻风博客 2023-04-21 原文

二手车交易的核心问题在于车况信息不透明。中国二手车交易市场制度尚不完善，长期以来缺少行业公认的车辆估值标准和车况检测标准，二手车商提供的估值和车况信息不够透明。这导致用户和车商交易双方都陷入了循环困境：用户对车商信任不足，购买意愿低。二手车商缺少潜在客户线索，为招揽客户不惜采用虚假信息，使得市场环境进一步恶化。
现阶段，多方面的车辆信息已实现了物理层面上的集成，但在语义内容的解析和信息的视觉呈现上还有待深入研究。用户需要亲自阅读碰撞、维保、电池报告来理解其中的内容，报告内容的丰富性、专业性与可读性将对用户的交易决策产生重要影响。例如，用户浏览APP时被汽车外观、内饰的照片所吸引，却可能因不了解汽车车体结构和车况排查标准而无法准确理解相应的碰撞、维保、电池报告中所包含的众多内容，最终导致交易转化失败。
为推动车况信息的透明化，汽车之家二手车不断完善优化“车史档案”，使二手车出险记录查得率达到98%、维保记录查得率达到85%，同时还有天天拍车平台开展线下检测业务，获取真实的车况数据完善档案数据。
传统二手车买车场景 VS 数字化二手车买车场景
通过利用数字能力和数据资源不断推动车况信息的透明化、标准化，使用户更易了解车况信息，提高用户决策效率和线索转化效率。具体来说，结合机器学习、自然语言处理和VR全景等技术，我们重塑了二手车购买的业务场景，将二手车车源在估值、车史、VR全景展示三个维度的信息进行了集成与融合，以交互式可视化的形式呈现给用户，使用户更快捷、直观、详尽了解二手车车源的车况和估值，降低用户的信息搜寻成本和信息理解成本，促进用户做出交易决策。
图1 传统二手车买车场景和数字化二手车买车场景对比
如图1所示，传统的二手车交易需要用户在不充分了解车辆信息的情况下与二手车商预约线下看车，再根据看车人的经验知识做出主观的评断。而数字化的二手车买车业务则是用户直接通过PC、APP从云端获取标准化的车辆信息，充分了解车辆信息、评估后再决定是否线下看车，有效提高线下看车的效率。汽车之家二手车在为用户创造数字化体验的过程中，除了促进购车交易，也提高了买车新模式的商业增长。

买车新模式：结构化数据+半结构化数据+全景数据
图2 二手车买车业务架构 
二手车买车业务流程架构如图2所示。结构化的数据来自从汽车之家二手车交易平台中的二手车的车辆数据、交易记录等数据。其中，二手车的车辆数据中包括省份、城市、车型、上牌时间、行驶里程、发布时间、过户次数等各种数据，二手车交易记录中包括成交价格、交易类型、检测车况等数据。这些结构化的数据按用于估值模型的训练，预测车辆在当前及未来的价格趋势。
半结构化的数据是指从第三方获取的车辆出险记录，4S店维修保养记录、天天拍线下检测记录以及电池数据记录，这些记录具有多种数据类型，需要转化为统一的数据格式，解析其中的语义内容，抽取结构化的信息。对于新能源车的电池数据经过加工解析生成电池在线检测报告，综合得出维保、碰撞、电池等多维度的车史报告。
全景数据是指通过VR外观相机和VR内饰相机所拍摄的原始图像数据，原始图像数据经过VR拍摄组件生成VR图片，再通过APP、H5端的VR播放组件进行展示。从非结构化数据中抽取出的结构化信息除了形成车史报告，也可以与VR中图像进行跨模态的语义对齐，例如车史报告中如提到“左前门碰撞”，则可以在VR展示中提示出左前门的状态异常。估值、车史和VR展示将共同呈现于用户界面。
当用户浏览通过PC、APP浏览二手车车源详情时，可在用户界面查看车辆估值信息，查询车史报告，VR全景看车，从价值、车况、外观内饰三个角度来评估车辆是否符合需求，决定是否购买或留下购车线索。

技术实现难点
估值：车辆的数据十分复杂，通常包括了区域、车龄、里程数、车型、车系、外观、内饰、车况等多达上百维的特征信息，并且这些特征存在着数据的部分缺失或特征间多重共线性的复杂关系，给二手车价格的预测模型带来三大挑战：模型预测的准确率、模型推理的计算效率、模型的可解释性。虽然现有的机器学习技术如神经网络或梯度提升树模型可以端到端地处理复杂特征，但车辆特征数据的复杂性使得此类方法不适合用于二手车价格的预测，已有的二手车估值模型准确率较低。为解决上述三个问题，本估值模型采用了分而治之的思路，将车源按照省份、城市和车型分组，再将分组后的车源数据中与时间相关的数据进行量化处理，根据相关性筛选特征，训练多元线性回归模型。
VR全景：现有的VR外观技术方案是采用单反相机+长焦镜头拍摄，在自带转盘的影棚内进行车辆外观的360°拍摄；或采用单反相机+鱼眼镜头拍摄，车内使用单反进行4面拍摄，然后采用人工后期处理的方式完成全景360°图像的生成。缺点在于单反+影棚+转盘造价高，条件苛刻，拍摄车辆需要专人负责运输，效率低，后期图像处理繁琐，产出一辆车的外观+内饰图片过程长，对于人员专业度要求苛刻。而通过手机APP引导拍摄+后期人工处理的方法所得图像不够精准，后期人工处理耗时长。二手车VR看车全新设计研发了基于模型、车辆轮廓识别、陀螺仪、磁场传感器综合性的对被摄车辆和场地进行计算，给拍摄者提供便捷的定位拍摄方案。
车史档案：维修保养记录、碰撞记录和电池充放电记录的数据也同样面临着数据维度巨大、数据质量不一、缺乏规范化的问题。比如维保记录和碰撞记录，有着多种形式的数据来源，既有半结构化的记录表单，也有记录文档，甚至还有拍摄或扫描的文档图像，需要对这些数据源进行加工处理，规范为统一格式的数据形式。在车况信息的抽取过程中，需要根据领域专家知识明确需要抽取的信息类型，建立车况评估和电池状况评估的知识模型以及相应的标准化术语词表，建立车况和电池的评分、评级模型。
实现方法
  • 估值
图3 估值模型 
对车辆进行估价，是二手车交易的重要环节，在交易过程中，需要根据车辆信息对二手车进行评估定价，获得较为准确估价区间。目前，我们基于汽车之家的二手车车源数据研发了一种车辆估价模型,来满足商家、用户对二手车车源价格的评估。
我们的车辆估价模型主要使用的车源数据包括：地理区域、车型、行驶里程、上牌时间、发布车辆时间等，首选我们需要车源数据中提取地理区域和车型，并按照地理区域、车型对车源数据中的其他维度数据进行分组，得到分组数据，再将分组后的车源数据中与时间相关的数据进行量化处理，处理后的各组车源数据作为训练数据，训练多元线性回归模型，模型定义如下：
其中，Y为估价，θ0为截距，变量t1为上牌时间，变量t2为行驶里程，变量t3为用户发布车辆信息时间，θ1、θ2、θ3为对应的回归系数。
表1 不同地理区域、不同车型对应估计模型的截距与回归系数
构建多个针对各个地理区域下的、不同车型的车辆估价模型，即每个省份对应多个车辆估价模型，每个省份、城市、车型下对应一个车辆估值模型。由于不同省份、车型的车辆价格存在一定的差异，因此针对不同地理区域、车型训练不同的估值模型，可以有效减少预测误差，使模型估计的准确性更高。得到针对各个地理区域下的、不同车型的截距与回归系数。
图4 根据信息预测估值&历史成交和建议
因此，本估值模型本质上是一个集成模型，顶层是按省份、城市和车型进行的分类模型，底层是对应类别的多个预测模型。当利用训练得到的车辆估价模型进行估价时，首先根据从客户端获取的地理区域、车型，选择与地理区域、车型相对应的车辆估价模型，再将从客户端获取的上牌时间、用户发布车辆信息时间、行驶里程输入以选取的模型，模型输出对应的高准确性的车辆估价。
  • VR全景
在VR技术逐渐普及，可为用户提供新颖的内容展现形式的背景下。因二手车一车一况，通过VR技术采集商家各辆车的内外图像数据，随车辆信息发布以后，可为用户提供更加直观、真实的车辆状况展示，线上车源360°展现，外观、内饰无死角细节浏览，提升浏览体验。提高用户决策及线索转化，提升到店转化率 。同时也为商家提供了高质线索和用户到店率。  
图5  VR全景拍摄技术流程
拍摄方案：载入用户选择的对应年代款的车辆模型图30张，一套360°外观图需要拍摄30张不同角度的照片，以车辆为圆心，12°为一个点，进行站位点划分，站位点与模型图角度进行强关联，每张图对应到一个站位点。使用手机内置陀螺仪+电子罗盘，经过计算可为拍摄者提供精准的角度位置信息，供拍摄者参考自身占位是否与模型图匹配；通过图像轮廓实时识别能力，为拍摄者提供精准的距离指引，免除人工丈量设置拍摄点位的繁琐步骤；当拍摄者按下拍摄按钮后，程序对拍摄的图片进行分析识别，保留车辆轮廓内的车辆清晰图片，对轮廓外的背景区域进行20%的高斯模糊图层生成，并对边缘进行羽化处理，拼合所有图层，得到最终的一个角度的外观图。本外观拍摄方案，简化了人工图像处理步骤，通过智能识别算法，全自动生成预期的车辆清晰背景虚化的外观图片，极大地简化了车辆外观360°的拍摄流程，10分钟内即可完成外观和内饰拍摄，并直接上传平台展示。
图6 VR全景多平台一体化集成方案
适配多端拍看一体化技术方案(手机App拍摄 + App双端VR播放组件 + H5VR播放组件):  1. 自研手机360°VR外观拍摄App组件；2. 自研集成化内饰VR拍摄组件, 支持多品牌VR相机连接拍摄；3. 自研App原生外观播放器控件；4. 基于ThreeSixty二次研发的外观H5播放器; 5. 基于Kpano的内饰360°H5内饰播放器。
  • 车史档案
图7 车史报告生成
图8 部分车史报告示例
图9 部分电池报告示例
车辆出险记录，4S店维修保养记录和天天拍线下检测记录数据形式多样，部分图片数据需要先通过OCR转换为统一的文档格式，再从文档中抽取结构化的信息。首先建立车况评估和电池状况评估的知识模型以及相应的标准化术语词表，解决了哪些信息需要被抽取，信息彼此之间的关系是什么，信息该如何利用的问题。具体来说，NLP模型抽取出时间信息，里程数、维修/理赔金额等数量信息，实体信息（汽车关键部位，如A柱、B柱等）及相应的方位词（如正前方、前方左侧等）和动词（如切割、钣金、焊接等），并根据句法标注建立实体、方位词和动词之间的关系，构成形如“左-A柱-焊接”的语义短语，这样的语义短语是描述车辆碰撞维修历史的最小语义单元。由于原始记录的不规范或OCR识别过程中的误差，记录文档对汽车关键部位的描述可能不够准确或不够完整，还需要依据预先建立的标准关键部位名词词表、动词词表、方位词词表进行规范化处理，得到标准化的关键部位名词、动词，以及相应的语义短语。
图10 车况排查分类的知识模型 & 图11：车史报告与VR图像的语义对齐
根据检测部位和事件类型，将车况排查分为骨架排查、加强件排查、水泡排查、火烧排查、里程排查、外观部件、变速箱/发动机排查、安全气囊排查8大维度。其中外观部件的排查信息可以与VR图像建立语义上的对齐，进而在VR层面进行视觉上的呈现。根据标准化的关键部位名词与动词关系，制定了不同维度的车况评级规则，将抽取出的标准化语义短语映射为“ABCD”四个等级评级，最后综合8个维度的评级和车辆的出险记录、理赔金额、新车指导价格等信息对车况做出综合的评估，分为“优、良、中、差”四个等级。从抽取的语义短语、事件和数量信息生成车辆的碰撞历史明细、维修保养历史明细和历史里程明细。
随着新能源汽车市场的迅猛发展，汽车之家二手车也积累了数万的新能源车源车主和对新能源车源有买车欲望的用户。除了获取车辆的维保、碰撞、里程车史，新能源车用户还对电池性能和电池续航能力的评估有着强烈需求。为此，二手车联合北理新源，利用新能源车电池大数据打造了新能源二手车智能车况云平台，将电池数据进行加工处理和评级，在汽车之家、二手车之家等相关产品上一键生成新能源电池一站式在线检测报告，实现电池性能实时评估和续航里程在线检测。
电池检测报告记录了电池出厂数据，并对电池评估数据、充放电数据、行驶数据和异常情况数据进行综合排查评估电池性能，计算出参考续航里程。综合解析以上维度的数据，构建了电池状况评分和评级模型，预测电池性能的评分并按照评分划分为优、良、中、差四个等级。

结语

针对二手车车辆数据和视觉展示进行了深度探究，我们建立了标准化的数据处理加工流程、方法模型以及可视化展示形式。面对海量的复杂的车辆数据，以分治思想建立估值的集成模型，极大提高了估值的准确性，使用户能够准确了解当前车辆的价值；建立标准化的车史知识模型，通过算法模型和规则方法将碰撞、维保、电池的信息结构化，特别是新能源车电池在线检测报告，在业内处于创新领导地位。在视觉展示层面，创新地利用软件技术解决了传统VR技术过于依赖硬件和人力导致的成本偏高，时间偏长的问题，使商家能够轻松地拍摄360°全景影像，提升购车用户的浏览体验。三个维度的信息经过数字技术解析并集成融合，重塑了二手车买车的业务数字化场景。
二手车买车业务是我们二手车非常关键的业务线，在用户做出交易决策的过程中，可信且完善的车辆信息以及信息与用户的交互起到至关重要的作用。汽车之家二手车的愿景是持续推动业务的数字化转型，打造二手车流通的全数字化系统，实现非标商品标准化，过程透明化，建立起一套赋能二手车行业数字化转型的新模式。
作者|缪西安
大数重塑sectiondatastrong大数据

有关大数据 + VR 全景技术重塑“二手车买车场景”的更多相关文章

  1. ruby - 解析 RDFa、微数据等的最佳方式是什么，使用统一的模式/词汇(例如 schema.org)存储和显示信息 - 2

    我主要使用Ruby来执行此操作，但到目前为止我的攻击计划如下:使用gemsrdf、rdf-rdfa和rdf-microdata或mida来解析给定任何URI的数据。我认为最好映射到像schema.org这样的统一模式，例如使用这个yaml文件，它试图描述数据词汇表和opengraph到schema.org之间的转换:#SchemaXtoschema.orgconversion#data-vocabularyDV:name:namestreet-address:streetAddressregion:addressRegionlocality:addressLocalityphoto:i

  2. ruby - Ruby 有 `Pair` 数据类型吗？ - 2

    有时我需要处理键/值数据。我不喜欢使用数组，因为它们在大小上没有限制(很容易不小心添加超过2个项目，而且您最终需要稍后验证大小)。此外，0和1的索引变成了魔数(MagicNumber)，并且在传达含义方面做得很差(“当我说0时，我的意思是head...”)。散列也不合适，因为可能会不小心添加额外的条目。我写了下面的类来解决这个问题:classPairattr_accessor:head,:taildefinitialize(h,t)@head,@tail=h,tendend它工作得很好并且解决了问题，但我很想知道:Ruby标准库是否已经带有这样一个类？ 最佳

  3. ruby - 我如何添加二进制数据来遏制 POST - 2

    我正在尝试使用Curbgem执行以下POST以解析云curl-XPOST\-H"X-Parse-Application-Id:PARSE_APP_ID"\-H"X-Parse-REST-API-Key:PARSE_API_KEY"\-H"Content-Type:image/jpeg"\--data-binary'@myPicture.jpg'\https://api.parse.com/1/files/pic.jpg用这个:curl=Curl::Easy.new("https://api.parse.com/1/files/lion.jpg")curl.multipart_form_

  4. 世界前沿3D开发引擎HOOPS全面讲解——集3D数据读取、3D图形渲染、3D数据发布于一体的全新3D应用开发工具 - 2

    无论您是想搭建桌面端、WEB端或者移动端APP应用，HOOPSPlatform组件都可以为您提供弹性的3D集成架构，同时，由工业领域3D技术专家组成的HOOPS技术团队也能为您提供技术支持服务。如果您的客户期望有一种在多个平台（桌面/WEB/APP，而且某些客户端是“瘦”客户端）快速、方便地将数据接入到3D应用系统的解决方案，并且当访问数据时，在各个平台上的性能和用户体验保持一致，HOOPSPlatform将帮助您完成。利用HOOPSPlatform，您可以开发在任何环境下的3D基础应用架构。HOOPSPlatform可以帮您打造3D创新型产品，HOOPSSDK包含的技术有：快速且准确的CAD

  5. FOHEART H1数据手套驱动Optitrack光学动捕双手运动(Unity3D) - 2

    本教程将在Unity3D中混合Optitrack与数据手套的数据流，在人体运动的基础上，添加双手手指部分的运动。双手手背的角度仍由Optitrack提供，数据手套提供双手手指的角度。 01  客户端软件分别安装MotiveBody与MotionVenus并校准人体与数据手套。MotiveBodyMotionVenus数据手套使用、校准流程参照：https://gitee.com/foheart_1/foheart-h1-data-summary.git02  数据转发打开MotiveBody软件的Streaming，开始向Unity3D广播数据；MotionVenus中设置->选项选择Unit

  6. 使用canal同步MySQL数据到ES - 2

    文章目录一、概述简介原理模块二、配置Mysql使用版本环境要求1.操作系统2.mysql要求三、配置canal-server离线下载在线下载上传解压修改配置单机配置集群配置分库分表配置1.修改全局配置2.实例配置垂直分库水平分库3.修改group-instance.xml4.启动监听四、配置canal-adapter1修改启动配置2配置映射文件3启动ES数据同步查询所有订阅同步数据同步开关启动4.验证五、配置canal-admin一、概述简介canal是Alibaba旗下的一款开源项目，Java开发。基于数据库增量日志解析，提供增量数据订阅&消费。Git地址：https://github.co

  7. 「Python｜Selenium｜场景案例」如何定位iframe中的元素？ - 2

    本文主要介绍在使用Selenium进行自动化测试或者任务时，对于使用了iframe的页面，如何定位iframe中的元素文章目录场景描述解决方案具体代码场景描述当我们在使用Selenium进行自动化测试的时候，可能会遇到一些界面或者窗体是使用HTML的iframe标签进行承载的。对于iframe中的标签，如果直接查找是无法找到的，会抛出没有找到元素的异常。比如近在咫尺的例子就是，CSDN的登录窗体就是使用的iframe，大家可以尝试通过F12开发者模式查看到的tag_name,class_name,id或者xpath来定位中的页面元素，会抛出NoSuchElementException异常。解决

  8. ruby-on-rails - 创建 ruby​​ 数据库时惰性符号绑定(bind)失败 - 2

    我正在尝试在Rails上安装ruby​​，到目前为止一切都已安装，但是当我尝试使用rakedb:create创建数据库时，我收到一个奇怪的错误:dyld:lazysymbolbindingfailed:Symbolnotfound:_mysql_get_client_infoReferencedfrom:/Library/Ruby/Gems/1.8/gems/mysql2-0.3.11/lib/mysql2/mysql2.bundleExpectedin:flatnamespacedyld:Symbolnotfound:_mysql_get_client_infoReferencedf

  9. STM32读取串口传感器数据（颗粒物传感器，主动上传） - 2

    文章目录1.开发板选择*用到的资源2.串口通信（个人理解）3.代码分析（注释比较详细）1.主函数2.串口1配置3.串口2配置以及中断函数4.注意问题5.源码链接1.开发板选择我用的是STM32F103RCT6的板子，不过代码大概在F103系列的板子上都可以运行，我试过在野火103的霸道板上也可以，主要看一下串口对应的引脚一不一样就行了，不一样的就更改一下。*用到的资源keil5软件这里用到了两个串口资源，采集数据一个，串口通信一个，板子对应引脚如下：串口1，TX：PA9，RX：PA10串口2，TX：PA2，RX：PA32.串口通信（个人理解）我就从串口采集传感器数据这个过程说一下我自己的理解，

  10. SPI接收数据异常问题总结 - 2

    SPI接收数据左移一位问题目录SPI接收数据左移一位问题一、问题描述二、问题分析三、探究原理四、经验总结最近在工作在学习调试SPI的过程中遇到一个问题——接收数据整体向左移了一位（1bit）。SPI数据收发是数据交换，因此接收数据时从第二个字节开始才是有效数据，也就是数据整体向右移一个字节（1byte）。请教前辈之后也没有得到解决，通过在网上查阅前人经验终于解决问题，所以写一个避坑经验总结。实际背景：MCU与一款芯片使用spi通信，MCU作为主机，芯片作为从机。这款芯片采用的是它规定的六线SPI，多了两根线：RDY和INT，这样从机就可以主动请求主机给主机发送数据了。一、问题描述根据从机芯片手

随机推荐