Researchers are no strangers to “search”: enter keywords, pull a batch of papers from a literature database, then judge one by one which are truly relevant. But take one step further along the literature—who is working in this direction, and who leads each team—and many people fall back on the most primitive method: open a notepad, write down author names one by one, and then look up each CV. Even after finding them, they still don't dare use them directly: there are so many people with the same name, and whether the affiliation matches is all down to guesswork.
MuchSci happens to have two features that address the two ends of this problem: paper search is responsible for “finding literature,” and talent profiling is responsible for “finding people.” This article breaks down the shared search philosophy behind them, and how to use MuchSci to connect the two features into one workflow and deliver a “direction + people” list.
01 One Philosophy, Two Applications
First, let's make the division of labor between the two features clear.
▲ Figure 1 | From defining the direction to delivering the list, search and profiling are two segments of the same pipeline
Search uses keywords to match literature in academic databases, while profiling uses names, affiliations, and CVs to match people in public sources. The inputs are different and the objects are different, but the action structure is exactly the same: both first “match,” then answer “is this match reliable?” For literature, you verify the source and relevance; for people, you verify whether the name, affiliation, and CV can be precisely matched. Once you understand this, the two features are not two isolated tools, but two applications of the same task to different objects.
02 Seen Side by Side, the Discipline Is the Same
Put the two features into the same comparison table, and the commonalities become clearer.
▲ Figure 2 | The objects, inputs, and verification content differ, but “how to confirm reliability after a match” is the same question
The row most worth comparing is “ambiguity handling.” When search encounters results with insufficient relevance, it discards them; when profiling encounters records that don't match, it marks them “to be verified” and does not count them as experts. Neither takes the “close enough, just accept it” route. This is no coincidence—if an irrelevant paper slips into the literature database, the citation is wrong; if a person who doesn't match slips into the list, the credibility of the entire inventory collapses. Better to include a few fewer entries than to treat results of unclear provenance as reliable conclusions—this is a discipline shared by search-related work.
Another correspondence lies in what is verified. Search verifies the literature source and indexing information; profiling verifies the CV and affiliation in public sources—both are facts that can be verified against external sources, rather than subjective judgments such as “is this paper good” or “is this person strong.”
Looking one step deeper, the two verification paths are actually mirror images.
▲ Figure 3 | The search side verifies “this paper is real and relevant,” while the profiling side verifies “this record refers to the same person”
Verification on the search side has three steps: the source is traceable and can be traced back to the indexing database and journal; relevance is judged, confirming that the content is indeed related to the research direction; irrelevant items are discarded, and tangential or doubtful items do not enter citations. The profiling side also has three steps: three-way matching, where name, affiliation, and CV are matched item by item; same-name differentiation, where records that do not match are not merged into one person; and isolation of doubtful records, which are marked for verification and not counted as experts. Both paths share one principle: results that fail verification should be discarded rather than forced into use.
03 What Is Delivered Is Not a List of Names, but a Three-Layer Interlocking List
Used alone, profiling produces individual profiles; connected with search, the deliverable is upgraded to a “direction + people” list.
▲ Figure 4 | Only when the direction layer, team layer, and profile layer are each verifiable does the list hold up
This list has three layers. The direction layer answers “which field to look at,” supported by the research scope, activity level, and representative literature defined during the search stage. The team layer answers “who is doing it,” mapping active teams, publication records, and institutional affiliations from the search results. The profile layer answers “who this person is,” carried by the four types of fields generated by profiling—basic information, education, employment history, and major research achievements.
The key to the three layers is that each is verifiable: the direction is supported by literature, the team by publication records, and the profile by data source identifiers. When others receive the list, they do not need to trust the person who compiled it; they can trace any layer back and find the basis. This is far more solid than a list of names and titles only.
04 Feature Interface: From Literature Dialogue to Person Profiles
In actual use, both features are under the tabs of the agent assistant, presented as two parallel entry points in the interface.
▲ Figure 5 | Paper search tab: conversational search, answering factual questions such as literature database size and per-search result limits
The search tab is a conversational interface: after you ask a question, the system calls the search tool and returns answers with sources—facts such as literature database coverage and the per-search return limit are provided directly and can be verified. After clarifying the direction and teams in this conversation, switch to the talent profiling tab and give the team leaders' names, affiliations, and CVs to profiling; what you get is the kind of structured profile broken down in previous articles. The output of search (direction, teams, leads) is exactly the input for profiling—the two features are separate in the interface but continuous in the workflow.
05 Boundaries
① This article discusses feature mechanisms and combined usage, and does not constitute a performance promise. The coverage of both search and profiling is limited, and the completeness of the list depends on the availability of public sources and literature databases.
② Structured does not mean evaluative. The list is an organization and presentation of public sources and does not constitute an ability evaluation, recommendation, or endorsement of any person; judgments involving specific individuals must be independently verified by the user, who bears responsibility.
③ Only public sources are used. No personal privacy data is involved; when used for formal purposes such as review or collaboration invitations, the current regulations and procedures of the relevant institutions shall prevail.