I am currently facing a similar challenge regarding pages with "too many" filters. Showing all of them and asking the user to scroll through all of them, while reading each and every one, seems to be a no-go.
The benchmark upon which we chose to work is the component used at mixpanel.com:
No filters are shown, just a "+ Add" button
All possible filters are then shown in a scrollable list. They are also divided by categories using both tabs on top of the list (the default one being "All") and separators inside the list. Recently used filters are always on top, which is a very nice touch in my opinion. If you hover over a filter, a description of the filter is shown on the right.
The key point in this implementation is sending the focus straight to the search, which filters the filter list as you type:
After selecting a parameter (filter) the user is presented with a component that is relevant to the type of data of that parameter: numeric only field for numeric value, generic text field for alphanumeric value, calendar for dates, switches for boolean choices, etc. The user can also set a logical operator for the input: equals, does not equal, is in range, is not in range, etc.
After confirmation, the filter is presented as a single line. If during the previous steps the user chose more than one option for a parameter (by ticking two or more checkboxes), those options are presented in a "this OR that" logic. If the user adds another filter, it will be added in a "this AND that" logic.
I see this as a very intuitive implementation for such a complex range of possibilities. One could certainly tweak this implementation, like removing the logical operation functionality, for example, to solve the "many filters" problem.
Now, for the problems:
This implementation is very different than what people are used to. It might require a second of learning, which is probably a deal breaker for e-commerce sites (but I don't believe that is the kind of project you're working on, right?)
This implementation kinda does away with traditional search. Your user wouldn't be able to find a smartphone by typing "smartphone" or "android" right away, since those would be "values" inside the "name" parameter.
It is more complex than it needs to be for simpler requests. Even the most straightforward user query would have to undergo a couple of steps and that user would be presented with quite a bit of information (filter categories, data type, logical operators..) that he or she didn't really ask for.
The main point I'm currently working on is adapting this to solve the "search for smartphone" problem. The challenge is returning results for both parameter names and parameter values at the same time in a clear and intuitive presentation.
Well, hope this helps you get going on your challenge.