C# Lucene-评分对子句计数的影响

我对Lucene有一些问题，因为它总是有一个固定的分数，它忽略了我的提升值

将parser rewriteMethod设置为SCORING\u BOOLEAN\u QUERY\u REWRITE确实起到了作用，但它对“clauseCount”有一个奇怪的副作用，我不太明白

随着不断得分，我对默认值为1024的maxClauseCount没有任何问题。随着动态评分，clauseCount很快超过1024，我真的很想知道这是为什么

有人知道这方面的技术细节吗

在另一篇帖子中，有人提到像“ca*”这样的查询被重写为“car或cars”。但是，无论你使用的是恒定的还是动态的评分，情况不应该总是这样吗

提前谢谢

编辑： 这是我的解决方案。我遇到了一些问题，因为我在创建文档时设置的文档提升值在以后获取文档时总是1.0。也许是个虫子，我不确定。我所知道的是，当你从搜索者那里得到一个文档时，文档对象是新创建的，boost值从未设置过。只有田地。可能与C#port有关。 无论如何，我编写了一个CustomScoreQuery，它使用原始查询并将分数与我在doc字段中设置的初始boost值相乘（我知道这是一个糟糕的解决方法）

说够了，这是我的密码。我愿意改进。特别是在不需要搜索者或字段的情况下，我可以获得原始的提升值

public class DynamicBoostingQuery : CustomScoreQuery
{
    private Searcher s;

    public DynamicBoostingQuery(Query q, Searcher searcher)
        : base(q)
    {
        this.s = searcher;
    }

    public override float CustomScore(int doc, float subQueryScore, float valSrcScore)
    {
        float val = base.CustomScore(doc, subQueryScore, valSrcScore);

        try
        {
            Document d = s.Doc(doc);

            float priority = float.Parse(d.Get("raw_categoryPriority"));

            return val * priority;
        }
        catch
        {
            return val;
        }        
    }
}

MultiTermQuery的默认值（在Java上的Lucene 3.5中，不知道引入的确切版本）是常量分数自动重写默认值，该默认值使用常量分数布尔查询重写，仅在定义的子句和命中阈值以下，然后切换到常量分数过滤器重写，这不会引发太多的循环。你重写了它，强迫Lucene使用BooleanQuery重写。不幸的是，如果您需要分数，则没有使用基于过滤器的重写的选项

---

也许您可以尝试使用CustomScoreQuery恢复文档增强功能。

我明白了，谢谢！现在，与恒定分数、自动、重写默认值相比，评分、布尔、查询、重写的搜索质量非常差，即使没有任何改进。我将尝试CustomScoreQuery来规避这个问题。请阅读（Lucene始终是一个好主意——非常好的Javadocs）。文档增强在搜索时是不可用的——它会成倍增加到每个字段的有效增强中。也许这是一条向你敞开的道路——使用Fieldable.getBoost，我做到了。“在搜索时，对于检索到的文档，此方法始终返回1。”遗憾的是，它不会更改我的解决方案。哦，没那么糟。：）