上述例子是一个基于2个输入特征和4个参数的栅格函数，这4个参数是栅格函数在输入空间4个顶角的函数值；其他函数值是通过这些参数得到的插值。你也可以采用更高维度的栅格或者更细粒度网格参数来的到更灵活的函数。该类库利用Keras层对象tfl.layers.Lattice实现栅上述栅格。TensorFlow 栅格也提供了分段线性函数(tfl.layers.PWLCalibration Keras 层)来校准和规范化输入的特征到栅格函数可接受的输入范围：上述栅格例子是0到1。
没有被约束的模型在只有很少的训练样本覆盖的输入空间中，可能表现得出乎意料。如图所示，深度神经网络和梯度提升树的预测结果和测试集的真实结果相去甚远。
即便通常情况下正则化能够的到更稳妥的推断结果，但标准的正则化工具并不能确保模型在所有的输入空间里都表现的合理，特别是当输入空间的维度很高时。切换到简单、可控且行为可期的模型将以严重牺牲模型准确率作为代价。
TF Lattice使得在采用（高准确率）灵活模型的同时，通过一些选项，通过一些有语义意义的通识或是策略驱动的形状限制，向学习过程注入领域知识成为可能。例如，你可以指定，模型的输入相对于给定的输入应该是单调递增的。这些额外的领域知识可以帮助模型学习到训练数据以外的知识，并且使得模型的行为对用户来说是可期、可控的。
TensorFlow Lattice Librayy
TensorFlow Lattice 是一个类库用来训练有约束的、可解释的基于栅格的模型。栅格是一个插值查询表，可以用来近似数据中任意的输入-输出关系 。
多数的机器学习实践者都曾遇到过训练数据和实际运行时用以评估模型的样本差别很大的情况。因此，相对灵活的机器学习解决方案，如DNN和随机森林等，仅依赖于训练数据的模型，在训练数据集和验证数据集没有覆盖的输入空间的表现经常出乎意料甚至是疯狂的。这个问题在重要的政策和公平性约束条件可能被打破的案例下变得尤为严重
有一些场景我们还可以减法，比如分布式，故障恢复场景，还有Exactly Once等情况都是通用框架下的问题，但在防火墙安全领域的数据分析下是可以简化的。
还有语言实现层面，甚至硬件加速的方案，可以优化，尽量使单节点性能大幅提升，以我的经验，现在的硬件能力是可以支撑的。
我认为将一个通用流计算框架裁剪移植到防火墙里，也许是下下下一代防火墙上绕不开的关键特性，甚至是最关键特性。
最后
当然系统还有许多细节，比如状态存储的设计，灵活状态规则的定义，多状态表下决策的统一，柔性的处置机制，修正机制等等。
一个未来的产品，还有很多未来的因素，由于才疏学浅，可能一叶障目，仅出于最近几年的所学所思，供探讨
目前我觉得决策树及其衍生模型，包括随机森林，GBDT均适用于实时预测，可以使用的工程框架如 XGBoost 的 C++ 版本。
其可行性论文网上已经有很多。
关键技术指标在哪里?
首先防火墙都是以性能指标为参照，实现相同功能下以硬件代价小(成本)性能高为竞争力。
除了算法的领先，需要在架构上领先。无论使用机器学习，还是统计规则，都要在比过去大几个数量级的数据下提取特征为基础的。
也就是“数据量”与“计算速度”还有“灵活性”的能力要超过上一代。而这三者关系却是互斥的，需要做减法。
既然是“数据分析”是关键，我们看看现在有的技术Hadoop生态，显然可以处理大数据量，但是速度慢，成本高。
后起之秀 Spark / Flink 解决速度问题，但还是基于Hadoop生态，是一个通用框架，灵活性上更好，性能还是太慢。
而下下下一代防火墙被限定在一个固定输入的“数据分析”系统下，显然灵活性可以牺牲一些，数据量也可以牺牲一些，但速度绝对不能妥协，因为防火墙是嵌入在关键路径上的。
首先需要一个通用的深度解析引擎，能灵活将业务字段从流量中提取，显然当代防火墙都已经具备。
然后需要一个通用的计算分析引擎，能够缓存大量的关键数据，然后根据规则进行计算。
基于状态管理的流计算分析
首先这个不是新东西，做过状态防火墙的都知道，流表(Flow Session Table)就是基于流或会话关系的状态管理。
从会话产生，状态变迁到结束的过程，需要符合一定规律，这个规律是网络协议定义的，所有的检查都是基于这个状态进行叠加的。
对应到业务风险就是对业务状态的管理，一般来说正常人在线完成一个业务的平均值为30分钟以内。所以通常这个数据量只需要1个小时即可解决90%的场景，数据量的问题被减掉了。
然后是会话的key，在业务安全层面上，可以使用传统的IP，FlowId，但更需要使用的是AppId，UserId，DeviceId，SessionId这种业务维度的key，这是一个开放字段，但不会超过10种，需要通用支持，也就是从报文任意位置解析出来的字段，都可以作为这个状态的key。
业务中也可以同时有很多key的状态，需要进行聚合(AGG)关联(JOIN)或合并(UNION)。
第二个不确定就是规律，这个业务规律是无法事先定义的，没有协议，只能事后分析产生，所以机器学习和人工分析在这里需要能指导这个规律，具体不展开讲。
这个状态管理的计算也就是速度与灵活性的取舍，比如还是流表状态管理，这个显然是针对3层流量定制的状态管理，所以速度快。
但业务层面没法牺牲字段和计算表达的灵活性了，所以这里的功能和一个Flink CEP系统相似。(已经不少安全公司在云安全上使用了)
