jjeong

오늘은 연관검색어에 대해서 이야기를 해보려 합니다.

연관검색어에 대한 정의는 어떻게 될까요?

우선 정확하게 사전 같은 곳에 등록된 정의는 없는 것 같습니다. 아니면 제가 못찾았나 봅니다.

그래서 제가 생각한 연관검색어의 두 가지 정의에 대해 살펴 보도록 하겠습니다.

1. 입력한 단어와 유사한 검색어

즉, 입력한 검색어를 포함하고 있는 검색어를 추천해서 보여주는 방식이 될 것 같습니다.

이와 비슷한 방식으로 적용된 곳이 네이버 지식쇼핑이 되겠습니다.

http://shopping.naver.com/search/all.nhn?query=%EB%82%98%EC%9D%B4%ED%82%A4&cat_id=&frm=NVSHATC

2. 입력한 단어와 같은 검색어를 입력한 사람들이 입력한 검색어

이 정의는 기본 전제(가정)이 있어야 합니다.

즉, 

두 가지 전제(가정) 입니다.

이와 같은 방식으로 미미박스의 연관검색어는 기능 구현이 되어 있습니다.

http://search.memebox.com/memebox/search?q=%EB%A9%80%ED%8B%B0%EC%8A%A4%ED%8B%B1&at=1&door=pc_sub&qt=box

1번의 경우 가장 빠르게 구현을 할 수 있습니다.

기본적으로 자동완성 기능을 제공 하고 있다면 자동완성 키워드 목록에서 유사 검색어를 추출 할 수 있습니다.

2번의 경우 검색 로그에 대한 수집과 분석이 함께 이루어져야 합니다.

1번 보다는 시간이 더 많이 걸리며 품질을 높이기 위한 방법을 계속 연구해야 합니다.

※ 본 글은 회사의 입장과는 전혀 상관이 없으며 개인적인 의견으로 작성된 글 임을 알려 드립니다.

이전 글에서 그냥 정확도 우선이라고 했지 그래서 어떻게 검색을 해야 하는지에 대한 설명이 부족했던 것 같습니다. 그래서 검색창에서 검색 하는 방법에 대해서 이야기를 해보려고 합니다.

이전 글)
[미미박스 검색이야기] 미미박스는 정확도 우선 검색 기능을 제공 합니다.

미미박스에서는 검색 시 입력한 검색어에 대한 Term Query 를 사용합니다.
즉, 입력한 검색어와 정확히 일치하는 단어가 상품 제목이나 설명 등에 포함이 되어 있어야 검색 결과로 제공이 가능 하다는 의미가 됩니다.

대부분의 e-커머스에서는 일반적인 웹문서와 같은 전문(fulltext) 검색을 적용하지 않으며 상품에 대한 특성과 속성에 맞는 검색 기법을 제공해 주게 됩니다.

미미박스 역시 전문 검색을 제공하지 않고 사용자가 입력한 검색어를 하나의 토큰 또는 최소 검색 일치 단어로 활용해서 검색을 수행하고 있으며, 자연어 처리에 대한 또는 서술형 질의에 대한 최적화 작업은 아직 미진합니다.

그럼 몇 가지 예를 들어 검색 활용 방법을 소개해 드리도록 하겠습니다.

Case 1) 특정 브랜드의 어떤 제품을 찾고 싶을 때

본비반트의 마스크팩을 찾을 경우

검색 질의어 및 결과 화면)

Case 2) 어떤 제품을 사용하는데 필요한 도구를 찾고 싶을 때

섀도우용 브러쉬를  찾을 경우

검색 질의어 및 결과 화면)

Case 3) 어떤 기능성을 가진 어떤 제품을 찾고 싶을 때

보습 기능을 가진 오일 제품을 찾을 경우

검색 질의어 및 결과 화면)

이와 같이 3가지 예를 들어 설명을 드렸습니다.

원하시는 상품을 찾는데 도움이 되셨으면 좋겠습니다.

※ 본 글은 회사의 입장과는 전혀 상관이 없으며 개인적인 의견으로 작성된 글 임을 알려 드립니다.

자동완성이란?

네이버 지식백과에서는 아래와 같이 나옵니다.

https://search.naver.com/search.naver?where=kdic&query=%EC%9E%90%EB%8F%99%EC%99%84%EC%84%B1&ie=utf8&sm=tab_nmr

그냥 제가 정의 하는 자동완성은 검색어에 대한 recommendation 이나 suggestion 기능이라고 생각 합니다.

미미박스에서 구현하고 있는 자동완성 기능은 아래와 같습니다.

기본은 검색결과가 있는 검색어를 대상으로 로그를 수집하며, 최근 일주일 데이터를 기반으로 Near Real Time 반영을 하고 있습니다.

이유는 좀 전까지 존재하던 검색어의 검색결과가 없어지게 되는 경우가 있습니다. 이를 반영해 주기 위해 NRT 색인을 하고 있습니다.

1. 초성 입력에 대한 검색어 제안이 가능 합니다.

검색어 입력) ㅁㅁㅂㅅ

2. 자소분리 입력에 대한 검색어 제안이 가능 합니다.

검색어 입력) 미밉 -> ㅁㅣㅁㅣㅂ

※ 자소 단위 검색은 입력한 자음과 모음을 분리해서 검색이 가능 하도록 해주는 기능 입니다.

3. 한영 변환에 대한 검색어 제안이 가능 합니다.

검색어 입력) alalqkrtm

※ 한영 변환의 경우 영타로만 입력이 가능 할 경우 유용하게 사용할 수 있는 기능이며 자동으로 지원 됩니다.

4. 자동완성 검색어에 대한 검색 베스트 딜 제안이 가능 합니다.

검색어 입력) 미미박스 브러쉬 (선택)

5. 자동완선 검색어에 대한 매칭 검색어에 강조 표기가 가능 합니다.

검색어 입력) 아임미미

6. 바로보기 라는 카테고리와 브랜드 필터 추천이 가능 합니다.

검색어 입력) 틴트

※ 바로보기 란? 우선 급하게 작명을 하다 보니 너무 뻔한 "추천필터", "추천카테고리", "추천브랜드" 등등으로 넣기가 싫었습니다. 하지만 개발자의 작명 실력으로 인해 이름과 기능에 대한 오해를 만들게 되었는데요. 이 기능은 검색어를 기반으로 한 추천 카테고리와 추천 브랜드를 보여주는 검색 필터링 기능 이며, 검색 결과 화면에서 제공되는 카테고리, 브랜드 필터 기능이 되겠습니다.

※ 저 추천 카테고리와 브랜드는 검색어가 완성형으로 입력이 되었을 때만 노출이 되게 됩니다. 이유는 사용자가 입력한 검색어를 조작하지 않기 위함이며 정확한 의도를 반영해 주기 위해서 이와 같이 구현하였습니다. 이 필터와 함께 사용하시면 원하시는 상품에 대한 대상을 좁혀서 검색을 하실 수 있게 됩니다.

좀 더 사용하기 편한 기능과 도움이 되는 정보를 제공드릴 수 있도록 노력 하겠습니다.

※ 본 글은 회사의 입장과는 전혀 상관이 없으며 개인적인 의견으로 작성된 글 임을 알려 드립니다.

[간단 요약]

미미박스 검색서비스에서는)

참고자료)

Precision 과 Recall

제가 미미박스에 합류하게 된 이유는

1. 검색 서비스에 대한 개발을 제가 주도적으로 할 수 있을 것 같아서와 

2. 해야할 게 많을 것 같다 라는

것 때문 이었습니다.

예전 미미박스 검색은 형태소 분석기에 의존적인 검색 기능을 제공하고 있었습니다.

이 방법이 틀렸다 나쁘다는 것은 절대 아닙니다.

단, 형태소 분석기 의존적으로 검색 기능을 제공하기 위해서는 사전 관리가 매우 중요합니다.

※ 여기서 사전관리는 포괄적인 사전 관리를 의미 하며, 단순 유의어/동의어 관리 수준을 의미 하는 것이 아닙니다.

미미박스에서는 검색 서비스는 아래와 같이 분리가 되어 진행 되고 있었습니다.

각 서비스 마다 제공되는 검색 기능이 달랐으며, 가장 중요하게 생각했던 서비스는 App 이였기 때문에 PC Web, Mobile Web에 대한 검색 기능 개선은 관심 밖이였던 것 같습니다.

보통 e-커머스 서비스에 들어오는 고객들은 크게 두 분류로 나뉘다고 생각 합니다.

이 두 고객의 행동 특성은 검색 관점에서 아래와 같이 분류 된다고 생각 합니다.

어쨌든 미미박스에서 검색서비스 기능은 통합 검색창 이외 어떤 기능도 제공이 되고 있지 않았습니다. (PC Web, Mobile Web)

단, native app은 일부 정렬과 검색 필터 기능을 포함하고 있었습니다.

그래서 미미박스 검색서비스를 완전 바닥 부터 새로 만들기로 하였습니다.

제가 처음 검색 개편을 이야기 하면서 e-커머스 에서 검색 서비스는 기본적으로 정확도(precision)가 중요하다고 이야기를 하였고 미미박스도 정확도 우선의 검색 서비스를 제공해 줘야 한다고 했습니다.

제가 제시한 정확도는 사용자가 입력한 검색어와 정확히 일치하는 문서에 대해서 검색이 되어야 한다는 것이었습니다.

이와 같이 변경이 될 경우 띄어쓰기는 매우 중요해 집니다.

예) 정확도 우선 시 검색어 적용 예시

1번은 "포니" + "립스틱" 라는 두 개의 검색어가 포함된 문서를 검색해 주며, 반드시 두 개의 검색어를 문서가 포함하고 있어야 합니다.

- 1번의 의도는 포니라는 제품과 립스틱 이라는 제품에 대한 AND 또는 OR 검색을 원한다고 생각 할 수 있습니다.

2번은 "포니립스틱" 라는 하나의 검색어가 포함된 문서를 검색해 줍니다.

- 2번의 의도는 포니립스틱이라는 단일 제품을 원한다고 생각 할 수 있습니다.

하지만 기존 사용자들은 정확도 우선으로 검색 경험을 가지고 있지 않았기 때문에 띄어쓰기에 대한 개념이나 활용에 대해서 인지를 못하고 있습니다. 여전히 띄어쓰기를 활용한 검색 패턴이 늘어나지 않고 있는 이유 이기도 한 것 같습니다.

결과적으로 검색을 하는 사용자들은 자신이 찾고자 하는 상품을 잘 찾을 수 있어야 하고 그 대상이 너무 많이 노출 되게 되면 상대적으로 상품을 클릭하기 보다 이탈을 하게 되는 경우가 많이 발생하게 됩니다.

이렇기 때문에 검색에서는 narrow down search 기능을 제공을 해줘야 하고 그에 맞는 검색 필터링 기능이 제공되어야 합니다.

좀 두서 없이 쓰다 보니 내용의 본질이 뭔지 전달이 잘 안되는 것 같내요.

정리 하겠습니다.

미미박스 검색서비스에서는)

앞으로 고객 요구에 맞는 검색 기능을 제공 할 수 있도록 노력 하겠습니다.

※ 본 글은 회사의 입장과는 전혀 상관이 없으며 개인적인 의견으로 작성된 글 임을 알려 드립니다.

오늘 부터 미미박스에서 검색 서비스에 대한 이야기를 블로그에 정리해 볼까 합니다.

개인적으로 회사에 소속되어 있으면서 서비스를 하고 싶은 방향에 맞춰서 빠르게 개발하고 적용 할 수 있다는게 얼마나 좋은지 모릅니다.

하지만 저희 팀에서 개발하고 배포하고 하면서 고객들에게 기능에 대한 설명이라던가 사용법에 대해서는 한번도 설명을 해주거나 도움을 주기 위한 채널을 만들지 못하는 것 같아 그냥 서비스에 대한 기능 위주로 어떻게 만들어졌고 어떻게 동작하는지 정리를 하고자 합니다.

생각 보다 잦은 기능 변경도 많고 눈에 띄는 것 그렇지 않은 것 등등 매주 많은 변화가 있지만 사실 사용하는 사람들에게는 뭐가 어떻게 바뀌었고 어떻게 사용해야 좋은지 전혀 전달해 주지 못했습니다.

이제 부터 하나씩 하나씩 미미박스 검색 서비스에 대한 이야기를 풀어 보도록 하겠습니다.

이게 또 언제 변수명이 바뀌었을까요?

버전 릴리즈 될때마다 소스코드를 다 따라 갈수가 없다 보니 이런 오류를 경험하게 되내요.

주의) min_should_match 는 java api 를 이용해서는 사용 할 수 없습니다.

[Terms Query]

OR)

AND)

[Bool Query + Terms Query]

OR)

AND)

봐야지 봐야지 하다 이제 봅니다.

제 눈에 띄는 것은 

원본링크)

Elasticsearch Core

Changes in 2.x:

• Extended Stats could return the wrong result when some indices are missing a field.
• Adding an object field with the same name as an existing field should fail.
• Shadow replicas should be considered as having size zero.
• CORS was broken for preflight requests.
• Windows users can configure the Windows service name, description, and user.
• Network addresses are now consistently displayed as the ip:port, instead of the hostname.

Changes in master:

• Network partitions will no longer cause loss of in flight documents, and we have the test to prove it.
• The `match`, `match_phrase`, and `match_phrase_prefix` queries are now separate queries, not just types of the `match` query.
• The task manager response now tells you which tasks can be cancelled, and supports a `_cat/tasks` API.
• Elasticsearch will no longer accept unquoted field names in JSON.
• Elasticsearch now uses mmapfs for Lucene directories instead of a hybrid of niofs/mmapfs.
• ParseField is now used to parse query names, which comes with deprecation logging for free.
• Geo-points support ignore_malformed correctly again.
• Moving averages threw an NPE when no window was specified.
• MappedFieldType should be responsible for knowing about which formatter apply, rather than the agg framework.
• The allocation-explain API now includes the configured allocation_delay and remaining_delays times.
• Hot threads now fail hard if the JVM doesn't support them.
• Queries now have a registry, and queries have gradually been migrated to use it.

Ongoing changes:

• Bulk request sizes will be subject to a circuit breaker.
• Deleted index tombstones are complicated.
• ObjectParser should allow constructor args.
• Should we enable http compression by default?
• Numeric and date fields in 5.0 should use the new Lucene points API.
• Now that we have removed the percolator API, we should also remove the percolator type and use percolator fieldsinstead.
• Improvements to how we score the _all field based on per-field boosts.

Apache Lucene

• The 6.0.0 release vote has passed and the bits were set free a few hours ago! Thank you Nick Knize for taking on the challenging role of release manager!
• Many geo3d improvements this week:
  • Polygon queries now accept Polygon... inputs, including random nested test polygons, matching our geo2d implementations and respecting the order of polygon vertices
  • Geo3d seems to sometimes incorrectly think a polygon is concave when it's really convex
  • Adjacent polygon points can now be coplanar
  • The unique GeoPath support, which matches all point within X distance of a specified path (think road trip, looking for sushi nearby), now has a simple factory API as well
  • Tests were not adequately testing the new simple factory methods for common shapes
  • Geo3d now uses a similar encode/decode quantization approach as LatLonPoint
  • After lively discussions, geo3d APIs no longer publicly expose classes and methods that could safely be private. APIs should start life private until proven worthy of being public!
• Many geo2d improvements as well:
  • LatLonPoint Polygon queries are faster using a cool pixelating grid approach, and we can do the same forGeoPointField
  • We must improve debuggability of our geo test failures with nice 3D earth models like this example
  • Here's a lively discussion about the pros and cons of having our geo tests quantize data only once
  • Quantization issues are tricky, and geo2d queries were quantizing the edges of box queries incorrectly, resulting in false positive hits
  • We have improved the geo2d tests to never allow "tolerance" on the returned results
  • We have moved common geo encoding APIs to core so they can be shared across implementations
  • Better random latitude/longitude generation for tests has exposed a tie-break bug in distance sorting, edge case bugs in box query, test bugs and polygon bugs
  • Rectangle and Polygon classes have graduated into Lucene's core, to enable sharing across our numerous geo implementations
  • A new encoding for GeoPointField will be consistent with LatLonPoint, and use all 64 available bits to minimize quantization error
  • GeoPointField gets an efficient distance sort
  • Randomized tests tried to create a too-big GeoPointDistanceQuery
  • We will move BaseGeoPointTestCase from the spatial module to test-framework allowing us to remove the dependency of the sandbox module on spatial
  • SloppyMath.haversin can now move to GeoUtils
• The classification module now computes the f1-measure
• A previously commented out test assertion comes half way back to life
• Our "getting started with Lucene" docs were a bit buggy, but now fixed thanks to a user asking about it
• We've upgraded our randomizedtesting dependency to 2.3.4, so we get better messages when there is a static leak in our tests
• Points were missing from the codecs package documentation
• The DataSplitter in Lucene's classification module should pay attention to classes when splitting
• 800+ new top-level-domains have been created since we last fixed StandardTokenizer to detect them, but we may need to wait for a JFlex release
• Highlighting fails to find terms inside the child query of a BlockJoinQuery
• Lucene doesn't have direct support for boolean subset matching, but a number of possible workarounds may work
• Math.toRadians is changing its results slightly between Java 1.8 and 1.9
• NRTCachingDirectory.listAll sometimes throws IllegalStateException
• A scary random test failure is hopefully caused by bad hardware or buggy JVM
• TestCoreParser gets some small improvements
• A possibly new JVM bug causes JVM crash when decoding postings
• JapaneseTokenizer should do a better job validating custom user-provided dictionaries
• Another iteration for codec level encryption; this patch uses a new initialization vector for each data block, and seems not to impact search performance
• Our release scripts still struggle with the switch from Subversion to git
• Sometimes, BooleanQuery's explain method can lie about its score
• Another user falls into the unfortunately common trap of thinking Lucene's stored fields store all information about a field

스탠포드 대학에서 제공하고 있는 IR-book 입니다.

참고하기 위해 스크랩 합니다.

원문링크)

원문목차)

Introduction to Information Retrieval: Table of Contents

각 챕터별 요약 원문)

Chap01. Information retrieval! using the Boolean model

-         상용 검색서비스의 대부분이 채택하고 있는 모델인 불리언 검색 모델에 대한 내용

-         AND, OR 등의 연산자를 포스팅 리스트를 통해서 어떻게 처리하고 있는지를 설명

è 현재 우리가 사용하고 있는 검색엔진의 작동 방식을 설명. 여러 관련 컴포넌트는 어떤것들이 있는지 등등…

Chap02. The dictionary and postings lists

-         빠른 검색을 위해 색인 처리를 하는데, 이를 구성하는 사전과 포스팅 리스트에 대한 내용

-         우리가 사용하고 있는 사전과 포스팅 외에도 다양한 용도의 다른 사전과 텀 포지션 정보들에 대해 설명

è 빠른 검색을 위해 문서의 정보를 검색엔진에 적합하도록 가공하는데 그것에 대한 결과물이죠.

Chap03. Tolerant retrieval! –

-         실데이터를 다룰 때 발생하는, 질의어 상에 또는 문서나 사전 상에, 여러 오류를 처리하는 내용

-         부분패턴 검색, k-Gram 처리, 오타처리, 동음어 처리 등에 대해 설명

è 검색 서비스를 위해서 꼭 필요한 유틸리티라 할 수 있는데 편의성과 융통성 등을 높여줍니다.

Chap04. Index construction

-         제한된 머신의 리소스 안에서 대용량의 색인을 처리하는 방법에 대한 내용

-         블록병합색인, 분산색인, 동적색인, 포지션 정보를 포함한 색인, 권한 정보를 포함한 색인

è 서비스 파트에서 열심히 하고 있는 작업이죠. 대용량의 색인을 할 때 필요한 지식입니다.

Chap05. Index compression

-         색인 데이터를 실제 메모리에 올려 사용해야 하기 때문에 성능을 고려한 압축이 필요. 그에 대한 내용

-         색인용량 예측방법(사전,포스팅), Dictionary압축, 블록저장, PostingFile압축, γ코드 압축, Zipf의법칙

è 데이터 특성에 따라 더 효율적인 압축도 가능합니다. 더 빠르게, 더 작게.. 맨날 하는 색인작업이 1시간 안에 끝난다면 좋겠죠.

Chap06. Term weighting and vector space models

-         단어 가중치 기법을 이용하여 질의어와 문서의 유사성 거리를 벡터 방식으로 풀어내는 검색 모델 소개

-         단어와 문서 구역에 대한 Scoring 및 Weighting, TF, IDF, TF*IDF, 가중치 정규화, 유사도 함수

è 불리언의 필터링 성격보다 보다 진보한 형태의 검색기법입니다. 질의와 문서의 유사도에 대한 개념이 시작됩니다.

Chap07. Computing scores in a complete search system

-         단어 가중치 기법 이외의 스코어링과 랭킹 기법에 대한 설명

-         스코어링과 랭킹, 챔피온 리스트, 품질 스코어링, Ordering, 스코어링용 Features, 스코어링 디자인

è 랭킹에 대한 가중치는 우리도 많이 사용하고 있죠. 더 좋은 검색 품질을 위해 끊임없이 개발해야 하는 부분입니다.

Chap08. Eval!uation in information retrieval!

-         검색 모델의 검색 성능 측정 방법에 대한 내용

-         테스트 콜렉션, 정확도와 재현율, 랭킹에 대한 평가, 적합도 판정, 시스템 품질과 사용성

è 검색 서비스의 오픈할 때 하는 성능측정 외에도 계속적인 평가와 모니터링이 필요합니다. 쿼리 파라미터의 뭘 수정해야 할까요??

Chap09. Relevance feedback and query expansion

-         사용자 피드백에 의한 재검색 모델과 질의어 확장에 대한 내용

-         최적화된 결과를 내놓기 위한 방법, Rocchio 알고리즘, 확률적 적합도, 질의 확장용 사전, 자동 시소러스 생성

è 쇼핑관련 검색서비스 등에 적용하면 좋은 모델입니다. 쿼리확장은 공통이지만 모호성이 있는 특히 지식, 뉴스, 일반 웹검색 등에 더욱 필요하죠.

Chap10. XML retrieval!

-         일반 텍스트가 아닌 구조적 텍스트인 XML 문서에 대한 검색 방법에 대한 내용

-         XML 문서, XML 검색 개요, XML 검색용 벡터 모델, 콘텐츠 중심과 구조적 중심의 검색 비교

è 그다지 새로운 개념은 아닙니다. 전처리파트에서 HTML, PDF, DOC, PPT 파일등을 XML로 가공해서 퍼주면 해야할 일들입니다.

Chap11. Probabilistic information retrieval!

-         확률적 검색 모델에 대한 내용

-         확률이론, 확률적 랭킹기법, 이진독립모델, 확률값(기대치) 추정, 다양한 확률 모델

è 불리언 검색의 대안 모델중에 하나인 확률모델입니다. 0/1 대신에 질의어에 대한 문서 적합성을 확률로 계산하죠.

Chap12. Language models for information retrieval!

-         언어적 특징(특정 단어가 실제로 쓰여질 확률)에 기반한 검색 모델 소개

-         Query likelihood model, Ponte & Croft 실험, 다양한 언어모델 기법

è 많이 쓰이는 단어 많이 쓰이지 않는 단어에 각기 다른 가중치를 두어 질의어를 가공하면 좀 더 주제가 명확한 결과가 나오겠죠.

Chap13. Text classification and Naive Bayes

-        문서 분류와 나이브 베이지안(확률적) 분류 기법에 대한 내용

-         문서 분류, Naïve Bayes 분류기법, Bernoulli 모델, 특징 추출, 상호 정보성(Mutual Information), 카이스퀘어 특징추출, 분류 평가

è 검색은 대규모의 컬렉션에서 사용자의 의도에 적합한 문서를 필터링하는 작업을 말하는데 이를 분류라고 표현할 수도 있습니다.
 유사성 혹은 관련성에 의한 분류 기법으로 검색품질을 높일수 있습니다. 서치 플러그인 등에서 사용하면 좋겠죠.

Chap14. Vector space classification

-         벡터 공간 모델에 의한 분류 기법에 대한 내용

-         Rocchio 분류, k-nearest neighbor(k근접이웃), 선형 및 비선형 분류, 분류의 tradeoff

è 유사하다는 개념을 어떻게 정의하면 좋을까요? 뚝딱 반으로 자를까요? 고려할 요소가 많아 복잡한건 어떻게 자를까요?

Chap15. Support vector machines and kernel functions

-         14장의 벡터공간모델에 의한 기계학습기법인 SVM에 대한 내용, 분류 기법에 대한 핵심 함수

-         SVM, 유연한 경계에 의한 분류, 비선형 SVMs

è 분류를 위한 대표적인 기계학습기법인 SVM입니다. 수학을 잘하면 재밋는데 못하면 재미없습니다. 
   결과가 주어졌을 때 x,y,z 등에 의한 선형분석입니다. 오류를 최소로 만드는 해를 찾는 기법이죠. 분류는 다 이런 식입니다.

Chap16. Flat clustering

-         비교사학습인 군집화 기법에 대한 내용 (vs 분류는 정답이 있는 교사학습기법), 평면적인 군집

-         정보검색에서의 군집화, 군집평가, k평균 알고리즘, EM 클러스터링

è 분류는 검색형태에 대한 의도를 품고서 문서를 솎아내는 방식이라 지속적으로 관리가 필요합니다. 구체적인 기획이 필요하죠.
   반면에 군집은 유사성이라는 척도 하나로 알아서 다해줍니다. 후처리에서 미리 해주면 검색품질이 엄청 좋아집니다.
   또는 검색엔진을 거친 후 재가공으로서 사후클러스터링을 하면 같은 질의어에 다른 내용의 문서들을 어느정도 모아서 볼여줄 수 있겠죠.

Chap17. Hierarchical clustering

-         구조적인(상향식, 하향식) 군집기법에 대한 내용

-         싱글링크&완전링크 군집화, 그룹핑 방식의 군집화, 중심축 기반의 군집화, 군집명명기법

è 앞에 군집기법은 좀 옛날겁니다. 요즈음은 인간의 군집화 방식을 좀 더 흉내내어 다 부순다음에 하나씩 모아가는 방식이거나
   또는 하나로 뭉쳐놓은 상태에서 아닌것들을 짤라내는 형식으로 군집화를 합니다. 제 논문도 이에 관련한거죠. 재밋습니다.

Chap18. Matrix decompositions and Latent Semantic Indexing

-         행렬분해와 잠재의미인덱싱 기법에 대한 내용 (요인분석과 차원축소를 이용한 인덱싱)

-         선형대수학, 행렬분해, 단어-문서 행렬, 고유값분해, 저차원 추정과 잠재의미색인(LSI)

è 행렬이 나오는데 아주 골치아프더군요. 내용인즉슨… 단어로 쪼개진 사전 기반의 색인방식을 해결하기 위한 대안으로 단어와 문서의 관계를 통째로 색인하자는거죠. 통째로 색인하면 콜렉션과 단어의 관계성이 그대로 살아있게됩니다. 그걸 그냥 쓰려니 너무 커서 줄여서 쓰는 방법을 고안한거죠.

Chap19. Web search basics

-         웹검색에 관련한 다양한 이슈들에 대한 내용

-         웹의 특징, 웹 그래프, 스팸, 웹광고, 웹검색 경향, fingerprint, 중복문서 해결기술과 Shingling

è 중복문서 제거입니다. 수집 문서중에서 많게는 70~80%가 중복이라는군요.
   이를 해결하기 위해 핑거프리트와 Shingling에 대해 소개하고 있습니다. 구글에 적용된 방식이기도 하구요. 스팸처리도 있군요.

Chap20. Web crawling and indexes

-         웹문서 수집과 색인에 대한 내용

-         Crawling, 크롤러 구조, DNS 처리방안, URL 프론티어, 분산색인, 병렬서버

è 누가 더 많이 수집하고 누가 더 빨리 처리해서 색인기에 집어 넣느냐는 절대적인 성능지표이죠.
   또 우리나라 검색회사가 글로벌로 성장해서 아시아의 모든 문서를 하나의 검색서비스로 제공한다면 어떻게 해야 할까요? 구글은 하고 있습니다.

Chap21. Link analysis

-         그래프 구조의 형태를 갖는 웹문서의 특징을 이용한 분석기법에 대한 내용 (구글의 Pagerank)

-         Pagerank, 마코브 체인, 페이지랭크 계산, 특정 토픽기반의 Pagerank, Hubs(참조) and Authorities(권위)

è 21세기 히트작이죠. 구글의 페이지랭크입니다. 이를 기회로 ‘사회적 네트워크’에 대한 관심이 폭발적으로 높아졌습니다.
   싸이월드도 그 대표적인 사례죠. 카페가 강점인 우리회사도 이를 충분히 이용할 수 있습니다. 블로그는 더더욱 그렇구요. 펌질~흐
   우리나라 사람들은 입소문을 잘 내기도 하고 군중심리도 있기 때문에 그래프 분석을 하면 검색에 큰 효과를 가져올 수 있을겁니다. 제가 궁극적으로 하고 싶은 분야도 이쪽입니다. 게시판의 글들을 컨셉별로 나눌수도 있고 관련 UCC를 연결할 수도 있겠죠. 잘~되면^^

[elasticsearch java api 리뷰]

원문 링크 : http://www.elasticsearch.org/guide/reference/java-api/search/

- 이 API는 검색 쿼리를 실행 할 수 있으며, 쿼리와 일치하는 결과를 구할 수 있습니다.

원문 예제 부터 살펴 보겠습니다.

- 두 개의 색인 파일에 대한 검색 조건을 생성 합니다. (index1 과 index2)

- 역시 각 index 에 대한 type을 지정 합니다.

- REST 방식으로 표현하게 되면 http://localhost:9200/index1,inde2/type1,type2/_search?....... 과 같이 됩니다.

  - http://www.elasticsearch.org/guide/reference/api/search/indices-types/

- termQuery 에서 multi 라는 field 에 test 라는 term 을 찾게 됩니다.

[Operation Threading Model]

- NO_THREADS : 호출된 쓰레드에서 실행

- SINGLE_THREAD : 또 다른 하나의 쓰레드를 생성하여 모든 shard 를 조회

- THREAD_PER_SHARD : 각 개별 shard 별로 쓰레드를 생성하여 실행

- Default SINGLE_THREAD 로 설정이 되어 있고, 성능적인 확인은 필요함.

[MultiSearch API]

- 개별 검색 조건에 대한 한번의 요청으로 각각의 검색 결과를 얻을 수 있습니다.

[Using Facets]

- http://www.elasticsearch.org/guide/reference/java-api/facets/

- facet 검색은 검색 결과에 대한 분류 또는 그룹핑으로 이해 하시면 접근 하시는데 조금 쉽습니다.

- termsFacet("f1") 에서 f1 은 facet name 입니다.

아래 부터는 테스트로 작성한 코드 입니다.

참고용으로만 사용하시기 바랍니다.

[기본 Query Search]

[Multi Search]

[MatchQeury]

[Multi MatchQuery]

[Facet Search]

- facet search 테스트를 위한 scheme 정보는 아래와 같습니다.