求解器与系统搜索的约束满足问题

Question

我们必须解决一个棘手的问题，我们需要针对一个系统检查来自多个来源的许多复杂规则，以确定该系统是否满足这些规则，或者应该如何更改以满足这些规则。

我们最初开始使用约束满足问题算法（使用Choco）来尝试解决该问题，但是由于规则和变量的数量将比预期的要少，因此我们希望建立一个所有可能配置的列表数据库，并根据规则使用多个请求来过滤此列表并以这种方式找到解决方案。

与针对合理数量的规则和变量使用CSP求解器算法相比，进行系统搜索是否有局限性或劣势？它会对性能产生重大影响吗？它将减少我们可以实施的约束类型吗？

作为示例：

您必须想象它具有更多的变量，更大的定义域（但始终是离散的）和更多数量的规则（以及更复杂的规则），但不能将问题描述为：

x in (1,6,9)
y in (2,7)
z in (1,6)
y = x + 1
z = x if x < 5 OR z = y if x > 5

并将其提供给求解器，我们将构建一个表：

X | Y | Z
1   2   1
6   2   1
9   2   1
1   7   1
6   7   1
9   7   1
1   2   6
6   2   6
9   2   6
1   7   6
6   7   6
9   7   6

并使用类似的查询（这只是一个示例，可以帮助您理解，实际上我们将针对语义数据库使用SPARQL）：

SELECT X, Y, Z WHERE Y = X + 1 
INTERSECT 
SELECT X, Y, Z WHERE (Z = X AND X < 5) OR (Z = Y AND X > 5)

Answer 1

CSP允许您将确定性的值生成（通过规则）与启发式搜索结合在一起。当您针对自己的问题定制两者时，美就发生了。规则只是一部分。同样重要的是搜索算法/生成器的选择。您可以剔除搜索空间的很多。

虽然我无法对您的SQL解决方案的性能做出预测，但我必须说，它使我感到有些round回。如果您的规则发生更改，则会发生一个特定的问题-您可能会发现必须从头开始。同样，RDBMS 将完全生成所有子查询，这些子查询可能会爆炸。

我建议使用CSP来实现一个工作原型，而使用SQL来实现一个原型，以实现您的需求的简单子集。然后，您将感觉良好，哪些有效，哪些无效。一定要考虑长期维护。

完全免责声明：我与CSP的最后一次接触是几十年前作为硕士课程的一部分在大学期间（我实现了一个CSP搜索引擎，与choco毫无二致，当然，它更基本，并且对该主题进行了一些研究）。但是从那以后这个领域肯定会发生发展。