终于面签完了，聊聊买房的痛点，最大的痛苦之处在于刷房源和选房。
现在比较典型的购房搜索的体验还是依赖筛选器，所以用户的搜索体验基本就是如下两种方式
a)筛选，粗粒度下，依靠条件组合获得结果
b)地铁找房、学区找房，但都是按区域可视化，目前还没调研到有什么好的推荐的产品
c)比较间接的手段，利用外部方式，比如UGC获得query，典型的比如楼盘，然后正常搜索后再次筛选
以上方式的效率都不算很高，而且会遇到比较典型的几个问题
a)二手房其实也算是种C2C的模式，而且价格弹性因素不小，其他因素也都弹性很大，不说环境、周边配套等因素，光是面积就会因为得房率不透明导致偏差，以实例来说，买家原始预算240w，因为在西二旗上班所以打算考虑13号线沿线，面积合理的小两居，使用筛选器只能筛到13号线+200~250w+70~90平+2居，那么以下房源本来是有希望符合要求的，
A.北京北，255w，价格可谈（因价格被滤掉）
B.龙泽苑，68平板楼，实际得房率90%以上（因面积被滤掉）
C.北京人家，离13号线有3站地的距离，但是离西二旗实际距离并不远（因不符合地铁沿线被过滤）
以上案例只有两种办法能在正常使用中被发现
用户实在找不到合适的了，扩大筛选再逐渐找到；
线下中介推荐，算是另一种不透明了。
b)第二个典型问题在于浏览效率偏低。使用初期就需要筛选器，而且每次都要使用筛选器，这本身就是效率很低的。使用筛选器后，由于是在一个很大的空间纯粹按时间排序做筛选，实际结果的可用率会相对比较低，尤其是用户已经觉得这个结果不靠谱了，下次来，这个结果可能仍然还在。
所以针对上面两个问题，简单设想一下产品设计
先说大头，整体策略层面需要做的，拆解需求的框架其实需要的是两类内容
a）推荐内容（符合某个定死的阈值下，排序尽量贴合接近用户需求的结果）=>用于初期刷房源
b）决策内容（收敛一定范围内，帮助用户决策的结果）=>用于最后决策
c）终极决策，这个靠算法肯定是搞不定的， 基本最多能做到的就是给用户呈现清楚利弊和几套推荐方案，用户自行拍板
那么第一层推荐内容我们来考虑怎么做
房产的机构化数据市面上有很多现成的，大部分结构化数据都可以作为影响因子，其中包含布尔值类型（限不限购、学不学区、有没有电梯等）、绝对数值类型（距离地铁距离、面积、房型等）和相对数值类型（环境、户型），布尔值和绝对数值的数据都是可以现成的，相对数值只要积累一定量用户也可以积累起来，尤其是有中介力量的话这批数值价值会很高。
比如我们可以拿这个表开搞。
我觉得……训练模型这种事情我搞不定，所以我选择了最low的方式，假设这些因子对决策的影响是线性的，也就是遵循先试试再说嘛……
好的，先人肉搞出一批假数据
如上面所说，绝对数值基本是参照真实，交通采用百度地图对我实际上班时间做了折算（实际交通打分应该考虑更周全一点，不关键，后续可以微调），相对数值则采用5分值比如环境。由于我的数学是体育老师教的，再多的因子我就算不过来了，先列这么多。
然后去找和我属性类似（单身、互联网圈）的小伙协助做心理预期打分，大概情况就是可以算出来
嗯，样本过少，所以最后这么多组θ的标准差不出意外的突破天际了，实际要用的话肯定不能这么随意，估计找中介+部分人工规范标注效果会好很多
算这么多组θ其实是有目的的，因为买房这种事情本来就是个人因素很强的东西，所以算出大众的θ不代表对个人合适，所以需要根据多组θ推算出调整因子的粒度，假设我们的模型是 最简单的f(x)=
那么我们可以通过交互手段让用户反馈某个θ是偏高还是偏低，例如用户认为某个房子“太贵了”，那么价格θ就应该适当加权，某个房子虽然交通很远但用户很满意，那么交通θ就不会是排序的重要因子。
如果引导顺利的话，通过这种方式训练几轮，就可以获得相对个性化的最终排序因子，这时候可以将数据全量灌入，按以下流程最终输出推荐房源的列表。
当然了这个还是假设，现在问题来了：挖掘技术哪家强？（呼唤专业人士）
