1.6 改进我们的模型
我们实现了可能有效的最愚蠢的模型，它也确实干得不错——93.4%的正确率。我们还能让它变得更好吗？
遗憾的是，对此没有通用的答案。除非你的模型预测已经100%正确，否则始终有可能改进，知道答案的方法只有一个：尝试各种方法，看看它们是否有效。构建好的预测模型涉及许多反复尝试，正确建立模型以快速迭代、试验和验证思路至关重要。
我们可以探索哪些方向？我可以不假思索地提出一些。
调整距离函数。我们在此使用的曼哈顿距离只是许多可能性中的一个，选择“正确”的距离函数通常是获得好模型的关键因素之一。距离函数（或者代价函数）本质上是向机器传达如何在其世界中考虑类似或者不同事物的手段，因此认真思考这一点是非常重要的。
搜索多个最靠近的点，而不是只考虑一个最近点，并进行“多数表决”。这可使模型变得更加健壮；观察更多的候选可以降低无意中选择错误对象的概率。这种方法有一个名称——“K最近邻”算法，是机器学习的经典方法之一。
对图像进行一些巧妙的处理。例如，想象拍摄一张照片，但是向右移动一个像素。如果将这个图像与原始版本比较，尽管它们是同一个图像，但距离可能很大。用于补偿这一问题的方法之一是使用某种模糊。用邻近像素颜色的平均值代替每个像素能够缓解“图像不重合”问题。
我敢肯定，你也能想到其他的主意，下面我们一起来探索第一种思路。
1.6.1 试验距离的另一种定义
我们从距离开始。为何不尝试一下高中已经学过的距离（学术上叫作“欧几里得距离”）？下面是这种距离的公式：
Dist(X,Y)=sqrt{(x_{1}-y_{1})^{2}+(x_{2}-y_{2})^{2}+ cdots + (x_{n}-y_{n})^{2}}
上述公式说明，两点X和Y之间的距离是对应坐标差值平方和的平方根。你可能已经见过这一公式的简化版本，如果取某个平面上的两个点：X=（x 1，x 2）和Y=（y 1，y 2），其欧几里得距离为：
Dist(X,Y)=\sqrt{(x_1-y_1)^2+(x_2-y_2)^2}相比数学，代码可能让你更舒服一些，下面是上式在F#中的表现形式：
let euclideanDistance (X,Y) =
Array.zip X Y
|> Array.map (fun (x,y) -> pown (x-y) 2)
|> Array.sum
|> sqrt```
我们取两个浮点数组作为输入（每个数组代表一个点的坐标），计算每个元素差值的平方，加总，再求平方根。这不是很难，而且相当清晰！
在此应该提到几个技术细节。首先，F#内建了许多很好的数学函数，通常可以在System.Math类中搜索。Sqrt就是这样一个函数——用let x = sqrt 16.0代替var x = Math.Sqrt(16)不是好多了吗？pown是另一个此类函数，它是指数为整数时“求n次方”的专用版本，通用版本则是**运算符，如let x = 2.0 ** 4.0。如果已知指数为整数，pown将明显提升性能。
另一个细节，我们在此使用的距离函数是正确的，但是从技术上说，对于我们的目的，实际上可以去掉sqrt。我们需要的是最接近的点，如果0≤A<B，则sqrt A<sqrt B。因此不必承担这一运算的代价，可以将其去掉。这使我们仅在整数上运算，比双精度数或者浮点数要快得多。
####1.6.2 重构距离函数
如果我们的目标是试验不同的模型，现在就是进行一些重构的好时机。我们希望更换代码中的不同部分，观察对预测质量的影响。具体地说，我们打算切换距离。典型的面向对象方法是提取一个接口（如IDistance），注入训练中（这就是C#示例中所做的）。然而，如果你真正地思考了这个问题，就会发现接口有些大材小用了——我们需要的只是一个函数，以两个点作为输入并返回一个整数——两点之间的距离。可以这样做。
程序清单1-11 重构距离函数type Distance = int[] * int[] -> int
let manhattanDistance (pixels1,pixels2) =
Array.zip pixels1 pixels2
|> Array.map (fun (x,y) -> abs (x-y))
|> Array.sum
let euclideanDistance (pixels1,pixels2) =
Array.zip pixels1 pixels2
|> Array.map (fun (x,y) -> pown (x-y) 2)
|> Array.sumlet train (trainingset:Observation[]) (dist:Distance) =
let classify (pixels:int[]) =
trainingset
|> Array.minBy (fun x -> dist (x.Pixels, pixels))
|> fun x -> x.Label
classify```我们创建一个Distance类型以代替接口，这是一个函数签名，以一对像素为参数，返回一个整数。现在可以传递任意多个Distance作为train函数的参数，这将返回使用特定距离的分类器。例如，我们可以用manhattanDistance函数或者euclideanDistance函数（或者想要进一步试验的任意距离函数）训练分类器，比较它们的表现。注意，这在C#中也完全可能做到。我们可以简单地使用Func，而不创建IDistance接口，下面是代码。
程序清单1-12 函数式C#示例
public class FunctionalExample
{
private IEnumerable<Observation> data;
private readonly Func<int[], int[], int> distance;
public FunctionalExample(Func<int[], int[], int> distance)
{
this.distance = distance;
}
public Func<int[], int[], int> Distance
{
get { return this.distance; }
}
public void Train(IEnumerable<Observation> trainingSet)
{
this.data = trainingSet;
}
public string Predict(int[] pixels)
{
Observation currentBest = null;
var shortest = Double.MaxValue;
foreach (Observation obs in this.data)
{
var dist = this.Distance(obs.Pixels, pixels);
if (dist < shortest)
{
shortest = dist;
currentBest = obs;
}
}
return currentBest.Label;
}
}```
这种方法的重点在于组成函数而不是对象，是典型的函数式编程。C#虽然来源于面向对象语言，但是也支持许多函数式方法。可以说，从3.5版本开始，C#中的每个特性和创新（LINQ、Async等）都是从函数式编程中借鉴的。现在，人们在描述C#时会说，它首先是面向对象的，但是支持函数式方法，而F#首先是一种函数式编程语言，但是也适应面向对象风格。在本书中，我们一般更强调函数式风格，而不强调面向对象风格，因为按照我们的看法，前者比后者更适合机器学习算法，还有一个原因是，以函数式风格编写的代码通常提供很大的优势。
在任何情况下，我们都要做好设置，观察自己的想法是否表现良好。现在，可以创建两个模型，比较它们的表现：let manhattanClassifier = train trainingData manhattanDistance
let euclideanClassifier = train trainingData euclideanDistance
printfn "Manhattan"
evaluate validationData manhattanClassifier
printfn "Euclidean"
evaluate validationData euclideanClassifier`
在此，最好的一件事是我们不需要在内存中重新加载数据集，只需要简单地修改脚本文件，选择包含所要运行新代码的部分，运行该部分即可。如果我们那么做，就应该看到新模型euclideanModel的分类图像的正确率为94.4%，而不是manhattanModel的93.4%。好极了！我们取得了1%的改进。1%看起来似乎不多，但是如果准确率已经达到93.4%，这就意味着错误率从6.6%降低到5.6%，有大约15%的收获。
从距离函数中的一个小变化，我们得到了很明显的改进。这似乎是一个有前景的方向，可能值得试验更复杂的距离函数，或者尝试前面提到的其他方向。如果不多加小心，就有可能因为多次试验而留下一大堆乱七八糟的代码。版本控制和自动化对经典软件开发是必不可少的，同样，在开发预测模型时，它们也是你的朋友。过程的细节和节奏可能不同，但是总体思路相同：你希望在对代码进行更改时不需要担心造成任何破坏，“在我的机器上可以正常工作”还不够好。在任何时候，任何人都应该可以使用你的代码，在没有任何人工干预的情况下复制你的结果。这种方法称作“可复制研究”。我强烈鼓励你朝着这个方向发展，尽可能在任何地方使用脚本和源代码控制。我自己曾经经历过这样的恐怖场景：前一天你的模型工作得很好，但是因为没有花时间清晰地进行保存，忘记了自己究竟是怎么做到的，从而弄丢了模型。不要成为那样的人！特别是在用Git或者Mercurial等DVCS创建分支如此容易的时代，没有任何借口犯那样的错误。对某个模型有新想法时，可以创建一个分支，保存在脚本中执行的步骤。