今天有客户通过在线QQ询问为什么在检索中，命中了很多不相干的数据。我已通过邮件回复了此客户。
觉得这个话题涉及到一些后台技术，特别是我们系统独特的检索点加工技术，可能对其他客户也有帮助，所以将回复内容摘录如下，供大家参考和交流：
由于keys配置文件中，引入了些检索点加工机制，比如“繁简兼容转换”、“大小写转换”、“全文检索转换”、“停用字转换”、“新旧ISBN兼容转换”以及二次代码随时扩展的其它转换函数等。其中“拼音字/词头转换”（pinyinab）这个加工机制，是提取拼音字头作为索引或检索词的。这个加工机制，常用于“题名拼音”和“责任者拼音”检索点构造中，它可能就是导致你们产生困惑的原因。你可以看看相关配置文件。
如果在：
<convert>
<string style="upper,pinyinab" />
</convert>
加了pinyinab这个加工机制，那么，数据保存时，"chong qing ren"的字段内容（比如“重庆人”书名的拼音），就会转换为"CQR"（上述转换机制中，还有upper这个转为大写的加工机制）存贮于系统相应检索表中。
如果在：
<convertquery>
<string style="upper,pinyinab" />
</convertquery>
加了pinyinab这个加工机制，它是转换前端检索词的，即读者输入的是" chong qing ren "的检索词，就会转换为"CQR"提交到数据库中，在相应检索表中查找。
在这种情况下，假如读者想检索一本英文书，书名是"Chinese"，他本意是想检索书名为"Chinese"的图书，但他选择的是全部检索路径，显然包含有“题名拼音”和“责任者拼音”这两个途径。那么，从这两个检索路径发起的检索请求，就会严格遵照keys中配置的检索点加工机制"pinyinab"进行处理，显然，此时，提交给系统的检索词，就会是"C"，假如读者还选择的是"前方一致"或"中间一致"，那么，"CQR"、"HCB"等也会被命中——也就是说，题名或责任者拼音中，可能会有很多很多检索点加工后，含"C"的索引内容了。返回到界面中，自然就是你们感觉到的不准确效果了。
从这个角度，程序是没有错的。囿于成本考虑，不太可能做些智能判断，看看什么是汉语拼音字母，什么是单词，从而有选择性地加工检索点或检索词。
那么，解决问题的办法有：
1、取消这个pinyinab的转换方式。让读者辛苦些，不能实现偷懒输入字头也能检索结果——事实上，我认为这个方式可能比较适合国情——拼音多是为不方便输入汉字的人，比如外国人了解信息和检索的，中国人检索，什么时候喜欢输入拼音呢？
2、在帮助或读者培训中，建议读者不要图省事而不选检索路径，如果能明确检索路径为“题名”，当然就会排除我们默认启用了的拼音字段检索点中的pinyinab加工机制了。——这个话题可以伸发出来对现在的OPAC中的检索路径选择的思考：现在在我们系统的简单检索界面风格中，要么是选“全部”，要么是选单一的检索路径，能否允许读者勾选多个库呢？这是可以考虑实现的（虽然高级检索界面风格中，可以实现这种数据库和检索路径的组配选择，但它易用性不够）。
注意，顺带提醒一下：
如果启用了pinyinab加工机制，那么，假如读者想用拼音字头检索“重庆人”的拼音索引，他得这么输入"C Q R"，即每个字母间用空格分隔，而如果不分隔，"CQR"这样的输入，会被检索词加工机制处理为"C"(抽字/词头嘛)，进行检索，也会命中很多不相关的东西。
如有更好的建议，欢迎继续交流。